draft-ietf-ieprep-framework-02.txt   draft-ietf-ieprep-framework-03.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT Ian Brown INTERNET DRAFT Ian Brown
Jun 24, 2002 UCL January 24, 2002 UCL
Framework for Supporting IEPS in IP Telephony Framework for Supporting ETS in IP Telephony
<draft-ietf-ieprep-framework-02.txt> <draft-ietf-ieprep-framework-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 36 skipping to change at page 1, line 36
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
For potential updates to the above required-text see: For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt http://www.ietf.org/ietf/1id-guidelines.txt
Abstract Abstract
This document presents a framework for supporting authorized This document presents a framework for supporting authorized
emergency related communication within the context of IP telephony. emergency related communication within the context of IP telephony.
We present a series of objectives that reflect a general view of how We present a series of objectives that reflect a general view of how
authorized emergency service, in line with the International authorized emergency service, in line with the Emergency
Emergency Preparedness Scheme (IEPS), should be realized within Telecommunications Service (ETS), should be realized within today's
today's IP architecture and service models. From these objectives, IP architecture and service models. From these objectives, we
we present a corresponding set of functional requirements, which present a corresponding set of protocols and capabilities, which
provide a more specific set of recommendations regarding existing provide a more specific set of recommendations regarding existing
IETF protocols. Finally, we present two scenarios that act as IETF protocols. Finally, we present two scenarios that act as
guiding models for the objectives and functions listed in this guiding models for the objectives and functions listed in this
document. These, models, coupled with an example of an existing document. These, models, coupled with an example of an existing
service in the PSTN, contribute to a constrained solution space. service in the PSTN, contribute to a constrained solution space.
^L
1. Introduction 1. Introduction
The Internet has become the primary target for worldwide communica- The Internet has become the primary target for worldwide communica-
tions. This is in terms of recreation, business, and various ima- tions. This is in terms of recreation, business, and various ima-
ginative reasons for information distribution. A constant fixture in ginative reasons for information distribution. A constant fixture in
the evolution of the Internet has been the support of Best Effort as the evolution of the Internet has been the support of Best Effort as
the default service model. Best Effort, in general terms, infers the default service model. Best Effort, in general terms, infers
that the network will attempt to forward traffic to the destination that the network will attempt to forward traffic to the destination
as best as it can with no guarantees being made, nor any resources as best as it can with no guarantees being made, nor any resources
reserved, to support specific measures of Quality of Service (QoS). reserved, to support specific measures of Quality of Service (QoS).
skipping to change at page 2, line 30 skipping to change at page 2, line 32
Internet architecture. This was followed by [3], which specified the Internet architecture. This was followed by [3], which specified the
RSVP signaling protocol used to convey QoS requirements. With the RSVP signaling protocol used to convey QoS requirements. With the
addition of [4] and [5], specifying control load (bandwidth bounds) addition of [4] and [5], specifying control load (bandwidth bounds)
and guaranteed service (bandwidth & delay bounds) respectively, a and guaranteed service (bandwidth & delay bounds) respectively, a
design existed to achieve specific measures of QoS for an end-to-end 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- 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 ence to a flow is one that is granular in definition and applying to
specific application sessions. specific application sessions.
From a deployment perspective (as of the date of this document), From a deployment perspective (as of the date of this document),
int-serv has been predominantly constrained to stub intra-domain int-serv has been predominantly constrained to intra-domain paths, at
paths, at best resembling isolated "island" reservations for specific best resembling isolated "island" reservations for specific types of
types of traffic (e.g., audio and video) by stub domains. [6] and traffic (e.g., audio and video) by stub domains. [6] and [7] will
[7] will probably contribute to additional deployment of int-serv to probably contribute to additional deployment of int-serv to Internet
Internet Service Providers (ISP) and possibly some inter-domain Service Providers (ISP) and possibly some inter-domain paths, but it
paths, but it seems unlikely that the original vision of end-to-end seems unlikely that the original vision of end-to-end int-serv
int-serv between hosts in source and destination stub domains will between hosts in source and destination stub domains will become a
become a reality in the near future (the mid- to far-term is a sub- reality in the near future (the mid- to far-term is a subject for
ject for others to contemplate). others to contemplate).
In 1998, the IETF produced [8], which presented an architecture for In 1998, the IETF produced [8], which presented an architecture for
Differentiated Services (diff-serv). This effort focused on a more Differentiated Services (diff-serv). This effort focused on a more
aggregated perspective and classification of packets than that of aggregated perspective and classification of packets than that of
[2]. This is accomplished with the recent specification of the [2]. This is accomplished with the recent specification of the
diff-serv field in the IP header (in the case of IPv4, it replaced 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- 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 blished by IANA, or set aside as experimental. It can be expected
that sets of microflows, a granular identification of a set of pack- that sets of microflows, a granular identification of a set of pack-
ets, will correspond to a given code point, thereby achieving an ets, will correspond to a given code point, thereby achieving an
aggregated treatment of data. aggregated treatment of data.
^L
One constant in the introduction of new service models has been the One constant in the introduction of new service models has been the
designation of Best Effort as the default service model. If traffic 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 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 treated as Best Effort and uses what resources are made available to
it. it.
Beyond the introduction of new services, the continued pace of addi- Beyond the introduction of new services, the continued pace of addi-
tional traffic load experienced by ISPs over the years has continued tional traffic load experienced by ISPs over the years has continued
to place a high importance for intra-domain traffic engineering. The to place a high importance for intra-domain traffic engineering. The
explosion of IETF contributions, in the form of drafts and RFCs pro- explosion of IETF contributions, in the form of drafts and RFCs pro-
duced in the area of Multi Protocol Label Switching (MPLS), exempli- duced in the area of Multi Protocol Label Switching (MPLS), exempli-
fies the interest in versatile and manageable mechanisms for intra- fies the interest in versatile and manageable mechanisms for intra-
domain traffic engineering. One interesting observation is the work domain traffic engineering. One interesting observation is the work
involved in supporting QoS related traffic engineering. Specifically, involved in supporting QoS related traffic engineering. Specifically,
we refer to MPLS support of differentiated services [9], and the on- we refer to MPLS support of differentiated services [9], and the on-
going work in the inclusion of fault tolerance [10]. This latter going work in the inclusion of fast bandwidth recovery of routing
item can be viewed as an example that is similar to "crank-back" (or failures for MPLS [10].
"auto-rerouting"), a term used to describe the means by which the
Public Switched Telephone Network (PSTN) routes around congested
switches.
1.1. Emergency Related Data 1.1. Emergency Related Data
The evolution of the IP service model architecture has traditionally The evolution of the IP service model architecture has traditionally
centered on the type of application protocols used over a network. centered on the type of application protocols used over a network.
By this we mean that the distinction, and possible bounds on QoS, By this we mean that the distinction, and possible bounds on QoS,
usually centers on the type of application (e.g., audio video tools) usually centers on the type of application (e.g., audio video tools)
that is being referred to. that is being referred to.
While protocols like SMTP [11] and SIP [12] have embedded fields While protocols like SMTP [11] and SIP [12] have embedded fields
denoting "priority", there has not been a previous IETF standards denoting "priority", there has not been a previous IETF standards
based effort to state or define what this distinction means with based effort to state or define what this distinction means with
respect to the underlying network and how it should be supported. respect to the underlying network or the end-to-end applications and
Given the emergence of IP telephony, a natural inclusion of it as how it should be supported at any layer. Given the emergence of IP
part of a telco carrier's backbone network, or into the Internet as a telephony, a natural inclusion of it as part of a telco carrier's
whole, implies the ability to support existing emergency related ser- backbone network, or into the Internet as a whole, implies the abil-
vices. Typically, one associates emergency calls with "911" tele- ity to support existing emergency related services. Typically, one
phone service in the U.S., or "999" in the U.K. -- both of which are associates emergency calls with "911" telephone service in the U.S.,
attributed to national boundaries and accessible by the general pub- or "999" in the U.K. -- both of which are attributed to national
lic. Outside of this exists emergency telephone services that boundaries and accessible by the general public. Outside of this
involved authorized usage, as described in the following subsection. exists emergency telephone services that involved authorized usage,
as described in the following subsection.
1.1.1. Government Emergency Telecommunications Service (GETS) 1.1.1. Government Emergency Telecommunications Service (GETS)
GETS is an emergency telecommunications service available in the U.S. GETS is an emergency telecommunications service available in the U.S.
and overseen by the National Communications System (NCS) -- an office and overseen by the National Communications System (NCS) -- an office
established by the White House under an executive order [30]. Unlike established by the White House under an executive order [30]. Unlike
"911", it is only accessible by authorized individuals. The majority "911", it is only accessible by authorized individuals. The majority
^L
of these individuals are from various government agencies like the of these individuals are from various government agencies like the
Department of Transportation, NASA, the Department of Defense, and Department of Transportation, NASA, the Department of Defense, and
the Federal Emergency Management Agency (to name but a few). In the Federal Emergency Management Agency (to name but a few). In
addition, a select set of individuals from private industry (telecom- addition, a select set of individuals from private industry (telecom-
munications companies, utilities, etc.) that are involved in criti- munications companies, utilities, etc.) that are involved in criti-
cial infrastructure recovery operations are also provided access to cial infrastructure recovery operations are also provided access to
GETS. GETS.
The purpose of GETS is to increase the probability that phone service The purpose of GETS is to increase the probability that phone service
will be available to selected government agency personnel in times of will be available to selected authorized personnel in times of emer-
emergencies, such as hurricanes, earthquakes, and other disasters gencies, such as hurricanes, earthquakes, and other disasters that
that may produce a burden in the form of call blocking (i.e., conges- may produce a burden in the form of call blocking (i.e., congestion)
tion) on the U.S. Public Switched Telephone Network by the general on the U.S. Public Switched Telephone Network by the general public.
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
originated) attempts to establish the call through an IXC. 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 route the call through an alternate IXC. If alter-
nate 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 GETS is based in part on the ANSI T1.631 standard, specifying a High
and unrelated to other emergency services like "911". Probability of Completion (HPC) for SS7 signaling [13].
1.1.2. International Emergency Preparedness Scheme (IEPS) 1.1.2. International Emergency Preparedness Scheme (IEPS)
[18] is a recent ITU standard that describes emergency related com- [18] is a recent ITU standard that describes emergency related com-
munications over international telephone service (Note, this document munications over international telephone service. While systems like
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 GETS are national in scope, IEPS acts as an extension to local or
national authorized emergency call establishment and provides a national authorized emergency call establishment and provides a
building block for a global service. building block for a global service.
As in the case of GETS, IEPS promotes mechanisms like extended queu- As in the case of GETS, IEPS promotes mechanisms like extended queu-
ing, alternate routing, and exemption from restrictive management ing, alternate routing, and exemption from restrictive management
controls in order to increase the probability that international controls in order to increase the probability that international
emergency calls will be established. The specifics of how this is to emergency calls will be established. The specifics of how this is to
be accomplished are to be defined in future ITU document(s). be accomplished are to be defined in future ITU document(s).
1.2. Scope of this Document 1.2. Scope of this Document
The scope of this document centers on the near and mid-term support The scope of this document centers on the near and mid-term support
of IEPS within the context of IP telephony, though not necessarily of ETS within the context of IP telephony, though not necessarily
Voice over IP. We make a distinction between these two by treating 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 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- some form of application layer signaling is used to explicitly estab-
lish and maintain voice data traffic. This explicit signaling capa- lish and maintain voice data traffic. This explicit signaling capa-
bility provides the hooks from which VoIP traffic can be bridged to bility provides the hooks from which VoIP traffic can be bridged to
the PSTN. the PSTN.
An example of this distinction is when the Robust Audio Tool (RAT) An example of this distinction is when the Robust Audio Tool (RAT)
[14] begins sending VoIP packets to a unicast (or multicast) destina- [14] begins sending VoIP packets to a unicast (or multicast) destina-
tion. RAT does not use explicit signaling like SIP to establish an tion. RAT does not use explicit signaling like SIP to establish an
^L
end-to-end call between two users. It simply sends data packets to end-to-end call between two users. It simply sends data packets to
the target destination. On the other hand, "SIP phones" are host the target destination. On the other hand, "SIP phones" are host
devices that use a signaling protocol to establish a call signal devices that use a signaling protocol to establish a call signal
before sending data towards the destination. before sending data towards the destination.
One other aspect we should probably assume exists with IP Telephony 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] 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 makes an arguement that there is a maximum packet loss and delay for
VoIP traffic, and both are interdependent. For delays of ~200ms, a VoIP traffic, and both are interdependent. For delays of ~200ms, a
corresponding drop rate of 5% is deemed acceptable. When delay is corresponding drop rate of 5% is deemed acceptable. When delay is
skipping to change at page 6, line 35 skipping to change at page 5, line 33
voice has a lower threshold of loss than other elastic applications. voice has a lower threshold of loss than other elastic applications.
This places a higher burden on the problem space of supporting VoIP This places a higher burden on the problem space of supporting VoIP
over the Internet. This problem is further compounded when toll- over the Internet. This problem is further compounded when toll-
quality service is expected because it assumes a default service quality service is expected because it assumes a default service
model that is better than best effort. This in turn can increase the 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 probability that a form of call-blocking can occur with VoIP or IP
telephony traffic. telephony traffic.
Beyond this, part of our motivation in writing this document is to 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- provide a framework for ISPs and carriers so that they have an under-
standing of objectives and accompanying functional requirements used standing of objectives used to support ETS related IP telephony
to support IEPS related IP telephony traffic. In addition, we also traffic. In addition, we also wish to provide a reference point for
wish to provide a reference point for potential customers (users of potential customers in order to constrain their expectations. In
IEPS) in order to constrain their expectations. In particular, we particular, we wish to avoid any temptation of trying to replicate
wish to avoid any temptation of trying to replicate the exact capa- the exact capabilities of existing emergency voice service currently
bilities of existing emergency voice service currently available in available in the PSTN to that of IP and the Internet. If nothing
the PSTN to that of IP and the Internet. If nothing else, intrinsic else, intrinsic differences between the two communications architec-
differences between the two communications architectures precludes tures precludes this from happening. Note, this does not prevent us
this from happening. Note, this does not prevent us from borrowing from borrowing design concepts or objectives from existing systems.
design concepts or objectives from existing systems.
Section 2 presents several primary objectives that articulate what is Section 2 presents several primary objectives that articulate what is
considered important in supporting IEPS related IP telephony traffic. considered important in supporting ETS related IP telephony traffic.
These objectives represent a generic set of goals and capabilities These objectives represent a generic set of goals and desired capa-
attributed to supporting IEPS based IP telephony. Section 3 presents bilities. Section 3 presents additional value added objectives,
additional value added objectives. These are capabilities that are which are viewed as useful, but not critical. Section 4 presents
viewed as useful, but not critical in support of IEPS. Section 4 protocols and capabilities that relate or can play a role in support
presents a series of functional requirements that stem from the of the objectives articulated in section 2. Finally, Section 5
objectives articulated in section 2. Finally, Section 5 presents two presents two scenarios that currently exist or are being deployed in
scenarios in IEPS that currently exist or are being deployed in the the near term over IP networks. These are not all-inclusive
near term over IP networks. These are not all-inclusive scenarios, scenarios, nor are they the only ones that can be articulated ([38]
nor are they the only ones that can be articulated. However, they do provides a more extensive discussion on the topology scenarios
show cases where some of the functional requirements apply, and where
some do not. ^L
related to IP telephony). However, these scenarios do show cases
where some of the protocols of discussed in section 4 apply, and
where some do not.
Finally, we need to state that this document focuses its attention on Finally, we need to state that this document focuses its attention on
the IP layer and above. Specific operational procedures pertaining the IP layer and above. Specific operational procedures pertaining
to Network Operation Centers (NOC) or Network Information Centers to Network Operation Centers (NOC) or Network Information Centers
(NIC) are outside the scope of this document. This includes the (NIC) are outside the scope of this document. This includes the
"bits" below IP, other specific technologies, and service level "bits" below IP, other specific technologies, and service level
agreements between ISPs and carriers with regard to dedicated links. agreements between ISPs and carriers with regard to dedicated links.
2. Objective 2. Objective
The support of IEPS within IP telephony can be realized in the form The support of ETS within IP telephony can be realized in the form of
of several primary objectives. These objectives define the generic several primary objectives. From this set, we present protocols and
functions or capabilities associated with IEPS, and the scope of the capabilities (presented below in section 3) to be considered by
support needed to achieve these capabilities. From this generic set clients and providers of ETS type services. This document uses the
of objectives, we present specific functional requirements of exist- IEPREP requirements of [39, 40] as a guide in specifying the objec-
ing IP protocols (presented below in section 3). tives listed in this section.
There are two underlying goals in the selection of these objectives. 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 One goal is to produce a design that maximizes the use of existing IP
protocols and minimizes the set of additional specifications needed protocols and minimizes the set of additional specifications needed
to support IP-telephony based IEPS. Thus, with the inclusion of to support IP-telephony based ETS. Thus, with the inclusion of these
these minimal augmentations, the bulk of the work in achieving IEPS minimal augmentations, the bulk of the work in achieving ETS over an
over an IP network that is connected or unconnected to the Internet IP network that is connected or unconnected to the Internet involves
involves operational issues. Examples of this would be the estab- operational issues. Examples of this would be the establishment of
lishment of Service Level Agreements (SLA) with ISPs, and/or the pro- Service Level Agreements (SLA) with ISPs, and/or the provisioning of
visioning of traffic engineered paths for IEPS-related telephony traffic engineered paths for ETS-related telephony traffic.
traffic.
A second underlying goal in selecting the following objectives is to A second underlying goal in selecting the following objectives is to
take into account experiences from an existing emergency-type commun- take into account experiences from an existing emergency-type commun-
ication system (as described in section 1.1.1) as well as the exist- ication system (as described in section 1.1) as well as the existing
ing restrictions and constraints placed by some countries. In the restrictions and constraints placed by some countries. In the former
former case, we do not attempt to mimic the system, but rather case, we do not attempt to mimic the system, but rather extract
extract information as a reference model. With respect to con- information as a reference model. With respect to constraints based
straints based on laws or agency regulations, this would normally be on laws or agency regulations, this would normally be considered out-
considered outside of the scope of any IETF document. However, these side of the scope of any IETF document. However, these constraints
constraints act as a means of determining the lowest common denomina- act as a means of determining the lowest common denominator in speci-
tor in specifying technical functional requirements. If such con- fying technical functional requirements. If such constraints do not
straints do not exist, then additional functions can be added to the exist, then additional capabilities can be added to the baseline set.
baseline set of functions. This last item will be expanded upon in This last item will be expanded upon in the description of Objective
the description of Objective #3 below. #3 below.
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: The primary Objectives in support of authorized emergency calls:
^L
1) High Probability of Call Completion 1) High Probability of Call Completion
2) Interaction with PSTN 2) No loss of information when interacting with
3) Distinction of IEPS data traffic PSTN signaling
3) Distinction of ETS data traffic
4) Non-preemptive action 4) Non-preemptive action
5) Non-ubiquitous support 5) Non-ubiquitous support
6) Authenticated service 6) Authenticated service
The first objective is the crux of our work because it defines our The first objective is the crux of our work because it defines our
expectations for both data and call signaling for IP telephony. As expectations for both data and call signaling for IP telephony. As
stated, our objective is achieving a high probability that emergency stated, our objective is achieving a high probability that emergency
related calls (both data and signaling) will be forwarded through an related calls (both data and signaling) will be forwarded through an
IP network. Specifically, we envision the relevance of this objec- IP network. Specifically, we envision the relevance of this objec-
tive during times of congestion, the context of which we describe tive during times of congestion, the context of which we describe
skipping to change at page 8, line 37 skipping to change at page 7, line 31
is "probability", as opposed to assurance or guarantee -- the latter is "probability", as opposed to assurance or guarantee -- the latter
two placing a higher burden on the network. It stands to reason, two placing a higher burden on the network. It stands to reason,
though, that the word "probability" is a less tangible description though, that the word "probability" is a less tangible description
that cannot be easily quantified. It is relative in relation to that cannot be easily quantified. It is relative in relation to
other traffic transiting the same network. Objectives 4 and 5 listed other traffic transiting the same network. Objectives 4 and 5 listed
above help us to qualify the term probability in the context of other above help us to qualify the term probability in the context of other
objectives. objectives.
The second objective involves the interaction of IP telephony signal- The second objective involves the interaction of IP telephony signal-
ing with existing PSTN support for emergency related voice communica- ing with existing PSTN support for emergency related voice communica-
tions. As mentioned above in Section 1.2, standard T1.631 [26] tions. As mentioned above in Section 1.2, standard T1.631 [26] speci-
specifies emergency code points for SS7. Specifically, the National fies emergency code points for SS7. Specifically, the National Secu-
Security and Emergency Preparedness (NS/EP) Calling Party Category rity and Emergency Preparedness (NS/EP) Calling Party Category code
code point is defined for ISUP IAM messages used by SS7 [26]. Hence, point is defined for ISUP IAM messages used by SS7 [26]. =A0Hence,
our objective in the interaction between the PSTN and IP telephony when IP providers choose to interconnect with the PSTN, it is our
with respect to IEPS (and national indicators) is a direct mapping objective that this interaction between the PSTN and IP telephony
between related code points. with respect to ETS (and national indicators) is a semantically
straightforward, reversible mapping of comparable code points.
The third objective focuses on the ability to distinguish IEPS data The third objective focuses on the ability to distinguish ETS data
packets from other types of VoIP packets. With such an ability, packets from other types of VoIP packets. With such an ability,
transit providers can more easily ensure that service level agree- transit providers can more easily ensure that pre-existing service
ments relating to IEPS are adhered to. Note that we do not assume level agreements relating to ETS are adhered to. Note that we do not
that the actions taken to distinguish IEPS type packets is easy. assume that the actions taken to distinguish ETS type packets are
Nor, in this section, do we state the form of this distinction. We easy. Nor, in this section, do we state the form of this distinc-
simply present the objective of identifying flows that relate to IEPS tion. We simply present the objective of identifying flows that
versus others that traverse a transit network. relate to ETS versus others that traverse a transit network.
At an abstract level, the fourth objective pertains to the actions At an abstract level, the fourth objective pertains to the actions
taken when an IP telephony call, via a signaling protocol such as taken when an IP telephony call, via a signaling protocol such as
SIP, cannot be forwarded because the network is experiencing a form SIP, cannot be forwarded because the network is experiencing a form
of congestion. We state this in general terms because of two rea- of congestion. We state this in general terms because of two
sons: a) there may exist applications other than SIP, like H.248,
^L
reasons: a) there may exist applications other than SIP, like H.248,
used for call establishment, and b) congestion may come in several used for call establishment, and b) congestion may come in several
forms. For example, congestion may exist at the IP packet layer with forms. For example, congestion may exist at the IP packet layer with
respect to queues being filled to their configured limit. Congestion respect to queues being filled to their configured limit. Congestion
may also arise from resource allocation (i.e., QoS) attributed per may also arise from resource allocation (i.e., QoS) attributed per
call or aggregated sets of calls. In this latter case, while there call or aggregated sets of calls. In this latter case, while there
may exist resources to forward the packets, a signaling server may may exist resources to forward the packets, a stateful signaling
have reached its limit as to how many telephony calls it will support server may have reached its configured limit as to how many telephony
while retaining toll-quality service per call. Typically, one terms calls it will support while retaining toll-quality service per call.
this form of congestion as call blocking. Note that we do not Typically, one terms this form of congestion as call blocking. Note
address the case when congestion occurs at the bit level below that that we do not address the case when congestion occurs at the bit
of IP, due to the position that it is outside the scope of IP and the level below that of IP, due to the position that it is outside the
IETF. scope of IP and the IETF.
So, given the existence of congestion in its various forms, our So, given the existence of congestion in its various forms, our
objective is to support IEPS-related IP telephony call signaling and objective is to support ETS-related IP telephony call signaling and
data traffic via non-preemptive actions taken by the network. More data traffic via non-preemptive actions taken by the network. More
specifically, we associate this objective in the context of IP specifically, we associate this objective in the context of IP
telephony acting as part of the Public Telephone Network (PTN). telephony acting as part of the Public Telephone Network (PTN).
This, as opposed to the use of IP telephony within a private or stub 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- network. In section 5 below, we expand on this through the descrip-
tion of two distinct scenarios of IP telephony and its operation with tion of two distinct scenarios of IP telephony and its operation with
IEPS and the PSTN. IEPS and the PSTN.
It is important to mention that this is a default objective influ- It is important to mention that the fourth objective is a default
enced by existing laws & regulations. Those countries not bound by position influenced by existing laws & regulations of some countries.
these restrictions can remove this objective and make provisions to Those countries, regions, or private networks not bound by these res-
enforce preemptive action. In this case, it would probably be advan- trictions can remove this objective and make provisions to enforce
tageous to deploy a signaling system similar to that proposed in preemptive action. In this case, it would probably be advantageous
[15], wherein multiple levels of priority are defined and preemption to deploy a signaling system similar to that proposed in [15],
via admission control from SIP servers is enforced. 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 The fifth objective stipulates that we do not advocate the need or
expectation for ubiquitous support of IEPS across all administrative expectation for ubiquitous support of ETS across all administrative
domains of the Internet. While it would be desirable to have ubiqui- domains of the Internet. While it would be desirable to have ubiqui-
tous support, we feel the reliance of such a requirement would doom tous support, we feel the reliance of such a requirement would doom
even the contemplation of supporting IEPS by the IETF and the even the contemplation of supporting ETS by the IETF and the expected
expected entities (e.g., ISPs and vendors) involved in its deploy- entities (e.g., ISPs and vendors) involved in its deployment.
ment.
We use the existing GETS service in the U.S. as an existing example 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- in which emergency related communications does not need to be ubiqui-
tous. As mentioned previously, the measure and amount of support 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 provided by the U.S. PSTN for GETS does not exist for all U.S. IXCs
nor LECs. Given the fact that GETS still works within this context, 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 it is our objective to follow this deployment model such that we can
accomplish the first objective listed above -- a higher probability accomplish the first objective listed above -- a higher probability
of call completion than that of normal IP telephony call traffic. of call completion than that of normal IP telephony call traffic.
^L
Our final objective is that only authorized users may use the ser- Our final objective is that only authorized users may use the ser-
vices outlined in this framework. GETS users are authenticated using vices outlined in this framework. GETS users are authenticated using
a PIN provided to the telecommunications carrier, which signals a PIN provided to the telecommunications carrier, which signals
authentication to subsequent networks via the HPC class mark. In an authentication to subsequent networks via the HPC class mark. In an
IP network, the authentication center will need to securely signal IP network, the authentication center will need to securely signal
back to the IP ingress point that a given user is authorized to send back to the IP ingress point that a given user is authorized to send
IEPS related flows. Similarly, transit networks with IEPS SLAs must ETS related flows. Similarly, transit networks that chose to support
securely interchange authorized IEPS traffic. In both cases, IPSec ETS SLAs must securely interchange authorized ETS traffic. In both
authentication transforms may be used to protect this traffic. This cases, IPSec authentication transforms may be used to protect this
is entirely separate from end-to-end IPSec protection of user traffic. This is entirely separate from end-to-end IPSec protection
traffic, which will be configured by users. IP-PSTN gateways must of user traffic, which will be configured by users. IP-PSTN gateways
also be able to securely signal IEPS authorization for a given flow. must also be able to securely signal ETS authorization for a given
As these gateways are likely to act as SIP servers, we further con- flow. As these gateways are likely to act as SIP servers, we further
sider the use of SIP's security functions to aid this objective. consider the use of SIP's security functions to aid this objective.
3. Value Added Objective 3. Value Added Objective
This objective is viewed as being helpful in achieving a high proba- This objective is viewed as being helpful in achieving a high proba-
bility of call completion. Its realization within an IP network bility of call completion. Its realization within an IP network
would be in the form of new protocols or enhancements to existing would be in the form of new protocols or enhancements to existing
ones. Thus, objectives listed in this section are treated as value ones. Thus, objectives listed in this section are treated as value
added -- an expectation that their existence would be beneficial, and added -- an expectation that their existence would be beneficial, and
yet not viewed as critical to support IEPS related IP telephony yet not viewed as critical to support ETS related IP telephony
traffic. traffic.
3.1. Alternate Path Routing 3.1. Alternate Path Routing
This objective involves the ability to discover and use a different This objective involves the ability to discover and use a different
path to route IP telephony traffic around congestion points and thus path to route IP telephony traffic around congestion points and thus
avoid them. Ideally, the discovery process would be accomplished in avoid them. Ideally, the discovery process would be accomplished in
an expedient manner (possibly even a priori to the need of its an expedient manner (possibly even a priori to the need of its
existence). At this level, we make no requirements as to how the existence). At this level, we make no assumptions as to how the
alternate path is accomplished, or even at which layer it is achieved alternate path is accomplished, or even at which layer it is achieved
-- e.g., the network versus the application layer. But this kind of -- e.g., the network versus the application layer. But this kind of
capability, at least in a minimal form, would help contribute to capability, at least in a minimal form, would help contribute to
increasing the probability of call completion of IEPS traffic by mak- increasing the probability of call completion of IEPS traffic by mak-
ing use of noncongested alternate paths. We use the term "minimal 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 form" to emphasize the fact that care must be taken in how the system
provides alternate paths so it does not significantly contribute to provides alternate paths so it does not significantly contribute to
the congestion that is to be avoided (e.g., via excess the congestion that is to be avoided (e.g., via excess
control/discovery messages). control/discovery messages).
At the time that this document was written, we can identify two 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 work-in-progress areas in the IETF that can be helpful in providing
alternate paths for call signaling. The first is [10], which is alternate paths for call signaling. The first is [10], which is
focused on network layer routing and describes enhancements to the focused on network layer routing and describes a framework for
LDP specification of MPLS to help achieve fault tolerance. This in
itself does not provide alternate path routing, but rather helps ^L
minimize loss in intradomain connectivity when MPLS is used within a enhancements to the LDP specification of MPLS to help achieve fault
domain. 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 The second effort comes from the IP Telephony working group and
involves Telephony Routing over IP (TRIP). To date, a framework involves Telephony Routing over IP (TRIP). To date, a framework
document [19] has been published as an RFC which describes the document [19] has been published as an RFC which describes the
discovery and exchange of IP telephony gateway routing tables between discovery and exchange of IP telephony gateway routing tables between
providers. The TRIP protocol [22] specifies application level providers. The TRIP protocol [22] specifies application level
telephony routing regardless of the signaling protocol being used telephony routing regardless of the signaling protocol being used
(e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises (e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises
reachability and attributes of destinations. In its current form, reachability and attributes of destinations. In its current form,
several attributes have already been defined, such as LocalPreference several attributes have already been defined, such as LocalPreference
and MultiExitDisc. Additional attributes can be registered with and MultiExitDisc. Additional attributes can be registered with
IANA. Initially, we would recommend two attributes that would relate IANA.
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.
3.2. End-to-End Fault Tolerance 3.2. End-to-End Fault Tolerance
This topic involves the work that has been done in trying to compen- This topic involves the work that has been done in trying to compen-
sate for lossy networks providing best effort service. In particu- sate for lossy networks providing best effort service. In particu-
lar, we focus on the use of a) Forward Error Correction (FEC), and b) 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 redundant transmissions that can be used to compensate for lost data
packets. (Note that our aim is fault tolerance, as opposed to an packets. (Note that our aim is fault tolerance, as opposed to an
expectation of always achieving it). expectation of always achieving it).
skipping to change at page 12, line 33 skipping to change at page 10, line 51
increase in offered load has been injected into the network. This increase in offered load has been injected into the network. This
makes an arguement that the act of protection against loss has con- makes an arguement that the act of protection against loss has con-
tributed to additional pressures leading to congestion, which in turn tributed to additional pressures leading to congestion, which in turn
helps trigger packet loss. In addition, in using a ratio of 10:3, 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 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 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 delay of the packets as well as minor bursts of load in addition to
changes in jitter. changes in jitter.
The other form of fault tolerance we discuss involves the use of The other form of fault tolerance we discuss involves the use of
redundant transmissions. By this we mean the case in which an origi- redundant transmissions. By this we mean the case in which an
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- ^L
work than that of adding FEC packets. However, the encodings of the original data packet is followed by one or more redundant packets.
redundant packets can be of a different type (or even transcoded into At first glance, this would appear to be even less friendly to the
a lower quality) that produce redundant data packets that are signi- network than that of adding FEC packets. However, the encodings of
ficantly smaller than the original packet. the redundant packets can be of a different type (or even transcoded
into a lower quality) that produce redundant data packets that are
significantly smaller than the original packet.
Two RFCs [24, 25] have been produced that define RTP payloads for FEC Two RFCs [24, 25] have been produced that define RTP payloads for FEC
and redundant audio data. An implementation example of a redundant and redundant audio data. An implementation example of a redundant
audio application can be found in [14]. We note that both FEC and audio application can be found in [14]. We note that both FEC and
redundant transmissions can be viewed as rather specific and to a redundant transmissions can be viewed as rather specific and to a
degree tangential solutions regarding packet loss and emergency com- degree tangential solutions regarding packet loss and emergency com-
munications. Hence, these topics are placed under the category of munications. Hence, these topics are placed under the category of
value added objectives. value added objectives.
4. Functional Requirements 4. Protocols and Capabilities
In this section, we take the objectives presented above and specify a In this section, we take the objectives presented above and present a
corresponding set of functional requirements to achieve them. Given set of protocols and capabilities that can be used to achieve them.
that the objectives are predominantly atomic in nature, the Given that the objectives are predominantly atomic in nature, the
corresponding functional requirements are to be viewed separately measures used to address them are to be viewed separately with no
with no specific dependency upon each other as a whole. They may be specific dependency upon each other as a whole. Various protocols
complimentary with each other, but there is no need for all to exist and capabilities may be complimentary to each other, but there is no
given different scenarios of operation, and that IEPS support is not need for all to exist given different scenarios of operation, and
viewed as a ubiquitously available service. We divide the functional that ETS support is not viewed as a ubiquitously available service.
requirements into 4 areas: We divide this section into 4 areas:
1) Signaling 1) Signaling
2) Policy 2) Policy
3) Traffic Engineering 3) Traffic Engineering
4) Security 4) Security
4.1. Signaling 4.1. Signaling
Signaling is used to convey various information to either intermedi- 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 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 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 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 the voice data. This latter example could be realized in the form of
diff-serv code points in the IP packet. diff-serv code points in the IP packet.
In the following subsections, we discuss potential augmentations to In the following subsections, we discuss potential augmentations to
different types of signaling and state information to help support different types of signaling and state information to help support
the distinction of emergency related communications in general, and the distinction of emergency related communications in general, and
IEPS specifically. IEPS specifically.
^L
4.1.1. SIP 4.1.1. SIP
With respect to application level signaling for IP telephony, we With respect to application level signaling for IP telephony, we
focus our attention to the Session Initiation Protocol (SIP). focus our attention to the Session Initiation Protocol (SIP).
Currently, SIP has an existing "priority" field in the Request- Currently, SIP has an existing "priority" field in the Request-
Header-Field that distinguishes different types of sessions. The Header-Field that distinguishes different types of sessions. The
five currently defined values are: "emergency", "urgent", "normal", five currently defined values are: "emergency", "urgent", "normal",
"non-urgent", "other-priority". These values are meant to convey "non-urgent", "other-priority". These values are meant to convey
importance to the end-user and have no additional sematics associated importance to the end-user and have no additional sematics associated
with them. with them.
[15] is a work in progress example that defines a new header field [15] is a (soon to be) RFC that defines the requirements for a new
for SIP known as the Resource Priority Header. This new header field header field for SIP in reference to resource priority. This new
is meant to provide an additional measure of distinction that can header field is meant to provide an additional measure of distinction
influence the behavior of gateways and SIP proxies. The structure of that can influence the behavior of gateways and SIP proxies.
the field is in the form of a NameSpace.Priority. The "NameSpace"
provides a reference point by which the "Priority" values correspond
to.
Additional namespaces and value(s) would be registered with IANA. It
would be our intention to follow the approach taken in [15] and
define a label for a new optional field in SIP to distinguish IEPS
calls from other calls. Assuming [15] becomes the accepted practice,
we would also register a new namespace attributed to IEPS. We would
define a single value (e.g., "authorized-emergency") that would
correspond to the single NS/EP code point of SS7. This will help
facilitate a seamless interaction between the PSTN and an IP network
acting as either an internal backbone or as a peering ISP.
This document does not specify the exact actions taken by a SIP node
upon receipt of the label corresponding to IEPS (authorized-
emergency) calls. This is a function of policy and to be articulated
in a separate document. We can speculate that in following the
objective of increased probability of call completion, there will be
a separate queue for IEPS-labeled calls. If a threshold for number
of calls exists within the SIP server one action may simply be "hold-
ing" the IEPS labeled request for an additional period in case a new
call can be placed. However, we stress this is only an example to
consider.
Note #1: Previous work that has been put forth by Polk in [34], which
describes an architecture for MLPP over IP networks, is similar to
the subject of IEPS in the sense that both aim at distinguishing cer-
tain VoIP flows from others. However, MLPP and IEPS are not the same
efforts. One critical difference is that MLPP involves the use of
preemption, while the default model for IEPS is simply an increase in
the probability of call completion.
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 4.1.2. Diff-Serv
In accordance with [16], the differentiated services code point In accordance with [16], the differentiated services code point
(DSCP) field is divided into three sets of values. The first set is (DSCP) field is divided into three sets of values. The first set is
assigned by IANA. Within this set, there are currently, three types assigned by IANA. Within this set, there are currently, three types
of Per Hop Behaviors that have been specified: Default (correlating of Per Hop Behaviors that have been specified: Default (correlating
to best effort forwarding), Assured Forwarding, and Expedited For- to best effort forwarding), Assured Forwarding, and Expedited For-
warding. The second set of DSCP values are set aside for local or 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 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 for local or experimental use, but may later be reassigned to IANA in
case the first set has been completely assigned. case the first set has been completely assigned.
One candidate recomendation involves the specification of a new type One candidate approach to consider involves the specification of a
of Per-Hop Behavior (PHB). This would provide a specific means of new type of Per-Hop Behavior (PHB). This would provide a specific
distinguishing emergency related traffic (signaling and user data) means of distinguishing emergency related traffic (signaling and user
from other traffic. The existence of this PHB then provides a base- data) from other traffic. The existence of this PHB then provides a
line by which specific code points may be defined related to various baseline by which specific code points may be defined related to
emergency related traffic: authorized emergency sessions (e.g., various emergency related traffic: authorized emergency sessions
IEPS), general public emergency calls (e.g., "911"), MLPP. Aggre- (e.g., ETS), general public emergency calls (e.g., "911"), MLPP.
gates would still exist with respect to the bundling of applications Aggregates would still exist with respect to the bundling of applica-
per code point. Further, one would associate a forwarding paradigm tions per code point. Further, one would associate a forwarding
aimed at a low loss rate reflective of the code point selected. The paradigm aimed at a low loss rate reflective of the code point
new PHB could be in the form of a one or more code points that dupli- selected. The new PHB could be in the form of a one or more code
cate EF-type traffic characteristics. Policies would determine IF a points that duplicate EF-type traffic characteristics. Policies
measure of importance exists per EF-type code-point. 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 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 points of flows within a diff-serv domain. With EF, one can expect
admission control being performed at the edges of the domain. admission control being performed at the edges of the domain.
Presumably, careful traffic engineering would be applied to avoid Presumably, careful traffic engineering would be applied to avoid
^L
congestion of EF queues at internal/core merge points stemming from congestion of EF queues at internal/core merge points stemming from
flows originating from different ingress nodes of the diff-serv flows originating from different ingress nodes of the diff-serv
domain. However, traffic engineering may not be able to compensate domain. However, traffic engineering may not be able to compensate
for congestion of EF-type traffic at the domain's core routers. 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- Hence, a new PHB that has more than one code point to identify EF-
type traffic may address congestion by associating a drop precedence type traffic may address congestion by associating a drop precedence
for certain types of EF-type datagrams. Note that local policy and 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- SLAs would define which EF-type of traffic, if any, would be associ-
ated with a specific drop precedence. ated with a specific drop precedence.
Another candidate recomendation would be to define a new or fifth Another approach to consider would be to define a new or fifth class
class for the existing AF PHB. Unlike the other currently defined for the existing AF PHB. Unlike the other currently defined classes,
classes, this new one would be based on five levels of drop pre- this new one would be based on five levels of drop precedence. This
cedence. This increase in the number of levels would conveniently increase in the number of levels would conveniently correlate to the
correlate to the the levels of MLPP, which has five types of priori- levels of MLPP, which has five types of priorities. The five levels
ties. The five levels would also correlate to a recent effort in the would also correlate to a recent effort in the Study Group 11 of the
Study Group 11 of the ITU to define 5 levels for Emergency Telecom- ITU to define 5 levels for Emergency Telecommunications Service
munications Service (ETS). Beyond these other standardization (ETS). Beyond these other standardization efforts, the 5 levels
efforts, the 5 levels would provide a higher level of variance that would provide a higher level of variance that could be used to super-
could be used to supercede the existing 3 levels used in the other cede the existing 3 levels used in the other classes. Hence, if
classes. Hence, if other non-emergency aggregate traffic were other non-emergency aggregate traffic were assigned to the new class,
assigned to the new class, the highest drop precedence they are the highest drop precedence they are assigned to is (3) --
assigned to is (3) -- corresponding to the other four currently corresponding to the other four currently defined classes. Emergency
defined classes. Emergency traffic would be set to (4) or (5), traffic would be set to (4) or (5), depending on the SLA that has
depending on the SLA tht has been defined. been defined.
It is important to note that as of the time that this document was 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 written, the IETF is taking a conservative approach in specifying new
PHBs. This is because the number of code points that can be defined PHBs. This is because the number of code points that can be defined
is relatively small, and thus understandably considered a scarce is relatively small, and understandably considered a scarce resource.
resource. Therefore, the possibility of a new PHB being defined for Therefore, the possibility of a new PHB being defined for emergency
emergency related traffic is at best a long term project that may or related traffic is at best a long term project that may or may not be
may not be accepted by the IETF. In the near term, we would ini- accepted by the IETF. In the near term, we would initially recommend
tially recommend using the Assured Forwarding (AF) PHB [20] for dis- using the Assured Forwarding (AF) PHB [20] for distinguishing emer-
tinguishing emergency traffic from other types of flows. At a gency traffic from other types of flows. At a minimum, AF could be
minimum, AF would be used for the different SIP call signaling mes- used for the different SIP call signaling messages. If EF was also
sages. If EF was also supported by the domain, then it would be used supported by the domain, then it would be used for IP telephony data
for IP telephony data packets. Otherwise, another AF class would be packets. Otherwise, another AF class would be used for those data
used for those data flows. flows.
It is critical to note that one cannot specify an exact code point 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 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- 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 bally unique per micro-flow or aggregate of flows). In addition, we
can expect that the existence of a codepoint for emergency related can expect that the existence of a codepoint for emergency related
flows is based on the service level agreements established with a flows is based on the service level agreements established with a
given diff-serv domain. given diff-serv domain.
^L
4.1.3. RTP 4.1.3. RTP
The Real-Time Transport Protocol (RTP) provides end-to-end delivery The Real-Time Transport Protocol (RTP) provides end-to-end delivery
services for data with real-time characteristics. The type of data services for data with real-time characteristics. The type of data
is generally in the form of audio or video type applications, and are is generally in the form of audio or video type applications, and are
frequently interactive in nature. RTP is typically run over UDP and frequently interactive in nature. RTP is typically run over UDP and
has been designed with a fixed header that identifies a specific type has been designed with a fixed header that identifies a specific type
of payload -- typically representing a specific form of application of payload representing a specific form of application media. The
media. The designers of RTP also assumed an underlying network pro- designers of RTP also assumed an underlying network providing best
viding best effort service. As such, RTP does not provide any effort service. As such, RTP does not provide any mechanism to
mechanism to ensure timely delivery or provide other QoS guarantees. ensure timely delivery or provide other QoS guarantees. However, the
However, the emergence of applications like IP telephony, as well as emergence of applications like IP telephony, as well as new service
new service models, presents new environments where RTP traffic may models, presents new environments where RTP traffic may be forwarded
be forwarded over networks that support better than best effort ser- over networks that support better than best effort service. Hence,
vice. Hence, the original scope and target environment for RTP has the original scope and target environment for RTP has expanded to
expanded to include networks providing services other than best include networks providing services other than best effort.
effort.
In 4.1.2, we discussed one means of marking a data packet for emer- 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 gencies under the context of the diff-serv architecture. However, we
also pointed out that diff-serv markings for specific PHBs are not also pointed out that diff-serv markings for specific PHBs are not
globally unique, and may be arbitrarily removed or even changed by globally unique, and may be arbitrarily removed or even changed by
intermediary nodes or domains. Hence, with respect to emergency intermediary nodes or domains. Hence, with respect to emergency
related data packets, we are still missing an in-band marking in a related data packets, we are still missing an in-band marking in a
data packet that stays constant on an end-to-end basis. data packet that stays constant on an end-to-end basis.
There are have three choices in defining a persistent marking of data There are three choices in defining a persistent marking of data
packets and thus avoid the transitory marking of diff-serv code packets and thus avoid the transitory marking of diff-serv code
points. We can propose a new PHB dedicated for emergency type points. One can propose a new PHB dedicated for emergency type
traffic as discussed in 4.1.2. We can propose a specification of a traffic as discussed in 4.1.2. One can propose a specification of a
new shim layer protocol at some location above IP. Or, we can add a new shim layer protocol at some location above IP. Or, one can add a
new specification to an existing application layer protocol. The new specification to an existing application layer protocol. The
first two cases are probably the "cleanest" architecturally, but they first two cases are probably the "cleanest" architecturally, but they
are long term efforts that may not come to pass because of a limited are long term efforts that may not come to pass because of a limited
amount of diff-serv code points and the contention that yet another 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 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 a marking in an application layer packet, also has drawbacks; the key
weakness being the specification of a marking on a per-application weakness being the specification of a marking on a per-application
basis. basis.
Discussions have been held in the Audio/Visual Transport (AVT) work- 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- ing group of augmenting RTP so that it can carry a marking that dis-
tinguishes emergency-related traffic from that which is not. Specif- tinguishes emergency-related traffic from that which is not. Specif-
ically, one would define a new extention that contains a "classifier" ically, these discussions centered on defining a new extention that
field indicating the condition associated with the packet (e.g., contains a "classifier" field indicating the condition associated
authorized-emergency, emergency, normal) [29]. The rationale behind with the packet (e.g., authorized-emergency, emergency, normal) [29].
this idea was that focusing on RTP would allow one to rely on a point The rationale behind this idea was that focusing on RTP would allow
of aggregation that would apply to all payloads that it encapsulates. one to rely on a point of aggregation that would apply to all pay-
However, the AVT group has expressed a rough consensus that placing loads that it encapsulates. However, the AVT group has expressed a
additional classifier state in the RTP header to denote the impor-
tance of one flow over another is not an approach that they 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 ^L
subsection concerning RTP in this document. We have decided to rough consensus that placing additional classifier state in the RTP
retain it because it is felt that information concerning directions header to denote the importance of one flow over another is not an
that should NOT be taken to support IEPS is important to the commun- approach that they wish to advance. Objections ranging from relying
ity at large. 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 that acts
as a signal should not be used.
4.1.4. MEGACO/H.248 4.1.4. MEGACO/H.248
The Media Gateway Control protocol (MEGACO) [23] defines the interac- The Media Gateway Control protocol (MEGACO) [23] defines the interac-
tion between a media gateway and a media gateway controller. [23] is 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 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 of applying the changes of RFC 2886 (Megaco Errata) to the text of
RFC 2885 (Megaco Protocol version 0.8). RFC 2885 (Megaco Protocol version 0.8).
In [23], the protocol specifies a Priority and Emergency field for a In [23], the protocol specifies a Priority and Emergency field for a
context attribute and descriptor. The Emergency is an optional context attribute and descriptor. The Emergency is an optional
boolean (True or False) condition. The Priority value, which ranges boolean (True or False) condition. The Priority value, which ranges
from 0 through 15, specifies the precedence handling for a context. from 0 through 15, specifies the precedence handling for a context.
The protocol does not specify individual values for priority. We The protocol does not specify individual values for priority. We
also do not recommend the definition of a well known value for the 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 MEGAGO priority. Any values set should be a function of any SLAs
that have been established regarding the handling of emergency that have been established regarding the handling of emergency
traffic. In addition, given that priority values denote precedence traffic. In addition, given that priority values denote precedence
(according to the Megaco protocol), then by default the IEPS data (according to the Megaco protocol), then by default the ETS telephony
flows should probably receive the same priority as other non- data flows should probably receive the same priority as other non-
emergency calls. This approach follows the objective of not relying emergency calls. This approach follows the objective of not relying
on preemption as the default treatment of emergency-related. on preemption as the default treatment of emergency-related.
4.2. Policy 4.2. Policy
One of the objectives listed in section 3 above is to treat IEPS- One of the objectives listed in section 3 above is to treat ETS- sig-
signaling, and related data traffic, as non-preemptive in nature. naling, and related data traffic, as non-preemptive in nature.
Further, that this treatment is to be the default mode of operation Further, that this treatment is to be the default mode of operation
or service. This is in recognition that existing regulations or laws or service. This is in recognition that existing regulations or laws
of certain countries governing the establishment of SLAs may not of certain countries governing the establishment of SLAs may not
allow preemptive actions (e.g., dropping existing telephony flows). allow preemptive actions (e.g., dropping existing telephony flows).
On the other hand, the laws and regulations of other countries On the other hand, the laws and regulations of other countries
influencing the specification of SLA(s) may allow preemption, or even influencing the specification of SLA(s) may allow preemption, or even
require its existence. Given this disparity, we rely on local policy require its existence. Given this disparity, we rely on local policy
to determine the degree by which emergency related traffic affects to determine the degree by which emergency related traffic affects
existing traffic load of a given network or ISP. Important note: we existing traffic load of a given network or ISP. Important note: we
reiterate our earlier comment that laws and regulations are generally reiterate our earlier comment that laws and regulations are generally
outside the scope of the IETF and its specification of designs and outside the scope of the IETF and its specification of designs and
^L
protocols. However, these constraints can be used as a guide in pro- protocols. However, these constraints can be used as a guide in pro-
ducing a baseline function to be supported; in our case, a default ducing a baseline capability to be supported; in our case, a default
policy for non-preemptive call establishment of IEPS signaling and policy for non-preemptive call establishment of ETS signaling and
data. data.
Policy can be in the form of static information embedded in various Policy can be in the form of static information embedded in various
components (e.g., SIP servers or bandwidth brokers), or it can be components (e.g., SIP servers or bandwidth brokers), or it can be
realized and supported via COPS with respect to allocation of a realized and supported via COPS with respect to allocation of a
domain's resources [17]. There is no requirement as to how policy is domain's resources [17]. There is no requirement as to how policy is
accomplished. Instead, if a domain follows actions outside of the accomplished. Instead, if a domain follows actions outside of the
default non-preemptive action of IEPS-related communication, then we default non-preemptive action of ETS related communication, then we
stipulate a functional requirement that some type of policy mechanism stipulate that some type of policy mechanism is in place to satisfy
is in place to satisfy the local policies of an SLA established for the local policies of an SLA established for ETS type traffic.
IEPS type traffic.
4.3. Traffic Engineering 4.3. Traffic Engineering
In those cases where a network operates under the constraints of 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 SLAs, one or more of which pertains to ETS based traffic, it can be
expected that some form of traffic engineering is applied to the expected that some form of traffic engineering is applied to the
operation of the network. We make no requirements as to which type operation of the network. We make no recommendations as to which
of traffic engineering mechanism is used, but that such a system type of traffic engineering mechanism is used, but that such a system
exists and can distinguish and support IEPS signaling and data exists in some form and can distinguish and support ETS signaling
traffic. We recommend a review by clients and providers of IEPS ser- and/or data traffic. We recommend a review of [36] by clients and
vice of [36], which gives an overview and a set of principles of prospective providers of ETS service, which gives an overview and a
Internet traffic engineering. set of principles of Internet traffic engineering.
MPLS is generally the first protocol that comes to mind when the sub- MPLS is generally the first protocol that comes to mind when the sub-
ject of traffic engineering is brought up. This notion is hightened ject of traffic engineering is brought up. This notion is heightened
concerning the subject of IP telephony because of MPLS's ability to concerning the subject of IP telephony because of MPLS's ability to
to permit a quasi circuit switching capability to be superimposed on permit a quasi-circuit switching capability to be superimposed on the
the current Internet routing model [33]. current Internet routing model [33].
However, having cited MPLS, we need to stress that it is an intra- 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. 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 Other forms of traffic engineering, such as weighted OSPF, may be the
mechanism of choice by an ISP. mechanism of choice by an ISP.
Note: As a point of reference, existing SLAs established by the NCS 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%) 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. of calls allowed to be established through a given LEC using HPC.
Once this limit is reached, all other GETS calls experience the same Once this limit is reached, all other GETS calls experience the same
probably of call completion as the general public. It is expected, probability of call completion as the general public. It is
and encouraged, that IEPS related SLAs will have a limit with respect expected, and encouraged, that ETS related SLAs will have a limit
to the amount of traffic distinguished as being emergency related, with respect to the amount of traffic distinguished as being emer-
and initiated by an authorized user. gency related, and initiated by an authorized user.
^L
4.4. Security 4.4. Security
As IEPS support moves from intra-domain PSTN and IP networks to dif- If ETS support moves from intra-domain PSTN and IP networks to
fuse inter-domain pure IP, authenticated service becomes more complex inter-domain end-to-end IP, authenticated service becomes more com-
to provide. Where an IEPS call is carried from PSTN to PSTN via one plex to provide. Where an ETS call is carried from PSTN to PSTN via
carrier's backbone IP network, very little IP-specific security sup- one carrier's backbone IP network, very little IP-specific security
port is required. The user authenticates herself as usual to the support is required. The user authenticates themself as usual to the
network using a PIN. The gateway from her PSTN connection into the network using a PIN. The gateway from the PSTN connection into the
backbone IP network must be able to signal that the flow has IEPS backbone IP network must be able to signal that the flow has an ETS
priority. Conversely, the gateway back into the PSTN must similarly label. Conversely, the gateway back into the PSTN must similarly
signal the call's higher priority. A secure link between the gateways signal the call's label. A secure link between the gateways may be
may be set up using IPSec or SIP security functionality. If the end- set up using IPSec or SIP security functionality. If the endpoint is
point is an IP device on the carrier's network, the link may be set an IP device on the carrier's network, the link may be set up
up securely from the ingress gateway to the end device. securely from the ingress gateway to the end device.
As flows traverse more than one IP network, domains whose peering As flows traverse more than one IP network, domains whose peering
agreements include IEPS support must have means to securely signal a agreements include ETS support must have the means to securely signal
given flow's IEPS status. They may choose to use physical link secu- a given flow's ETS status. They may choose to use physical link secu-
rity and/or IPSec authentication, combined with traffic conditioning rity and/or IPSec authentication, combined with traffic conditioning
measures to limit the amount of IEPS traffic that may pass between measures to limit the amount of ETS traffic that may pass between the
the two domains. The inter-domain agreement may require the two domains. The inter-domain agreement may require the originating
originating network to take responsibility for ensuring only author- network to take responsibility for ensuring only authorized traffic
ized traffic is marked with IEPS priority; the downstream domain may is marked with ETS priority; the downstream domain may still perform
still perform redundant conditioning to prevent the propagation of redundant conditioning to prevent the propagation of theft and denial
theft and denial of service attacks. Security may be provided of service attacks. Security may be provided between ingress and
between ingress and egress gateways or IP endpoints using IPSec or egress gateways or IP endpoints using IPSec or SIP security func-
SIP security functions. tions.
When a call originates from an IP device, the ingress network may When a call originates from an IP device, the ingress network may
authorize IEPS traffic over that link as part of its user authentica- authorize IEPS traffic over that link as part of its user authentica-
tion procedures without necessarily communicating with a central IEPS tion procedures without necessarily communicating with a central ETS
authentication center as happens with POTS-originated calls. These authentication center as happens with POTS-originated calls. These
authentication procedures may occur at the link or network layers, authentication procedures may occur at the link or network layers,
but are entirely at the discretion of the ingress network. That net- but are entirely at the discretion of the ingress network. That net-
work must decide how often it should update its list of authorized 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 ETS users based on the bounds it is prepared to accept on traffic
from recently-revoked users. from recently-revoked users.
5. Key Scenarios 5. Key Scenarios
There are various scenarios in which IP telephony can be realized, There are various scenarios in which IP telephony can be realized,
each of which can infer a unique set of functional requirements that each of which can infer a unique set of functional requirements that
may include just a subset of those listed above. We acknowledge that may include just a subset of those listed above. We acknowledge that
a scenario may exist whose functional requirements are not listed a scenario may exist whose functional requirements are not listed
above. Our intention is not to consider every possible scenario by above. Our intention is not to consider every possible scenario by
which support for emergency related IP telephony can be realized. which support for emergency related IP telephony can be realized.
Rather, we narrow our scope using a single guideline; we assume there Rather, we narrow our scope using a single guideline; we assume there
^L
is a signaling & data interaction between the PSTN and the IP network is a signaling & data interaction between the PSTN and the IP network
with respect to supporting emergency-related telephony traffic. We with respect to supporting emergency-related telephony traffic. We
stress that this does not preclude an IP-only end-to-end model, but 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 rather the inclusion of the PSTN expands the problem space and
includes the current dominant form of voice communication. includes the current dominant form of voice communication.
There are two scenarios that we use as a model for determining our Note: as stated in section 1.2, [36] provides a more extensive set of
objectives and subsequent functional requirements. These are: scenarios in which IP telephony can be deployed. Our selected set
below is only meant to provide an couple of examples of how the pro-
tocols and capabilities presented in Section 3 can play a role.
Single IP Administrative Domain Single IP Administrative Domain
------------------------------- -------------------------------
This scenario is a direct reflection of the evolution of the PSTN. This scenario is a direct reflection of the evolution of the PSTN.
Specifically, we refer to the case in which data networks have Specifically, we refer to the case in which data networks have
emerged in various degrees as a backbone infrastructure connecting emerged in various degrees as a backbone infrastructure connecting
PSTN switches at its edges. This represents a single isolated IP PSTN switches at its edges. This represents a single isolated IP
administrative domain that has no directly adjacent IP domains con- administrative domain that has no directly adjacent IP domains con-
nected to it. We show an example of this scenario below in Figure 1. nected to it. We show an example of this scenario below in Figure 1.
skipping to change at page 21, line 28 skipping to change at page 19, line 4
SW - Telco Switch SW - Telco Switch
SG - Signaling Gateway SG - Signaling Gateway
Figure 1 Figure 1
The significant aspect of this scenario is that all the resources of The significant aspect of this scenario is that all the resources of
each IP "island" fall within a given administrative authority. each IP "island" fall within a given administrative authority.
Hence, there is not a problem of retaining toll quality Grade of Ser- 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 vice as the voice traffic (data and signaling) exits the IP network
^L
because of the existing SS7 provisioned service between carriers. because of the existing SS7 provisioned service between carriers.
Thus, the need for support of mechanisms like diff-serv, and an 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 expansion of the defined set of Per-Hop Behaviors is reduced (if not
eliminated) under this scenario. eliminated) under this scenario.
Another function that has little or no importance within the closed Another function that has little or no importance within the closed
IP environment of Figure 1 is that of IP security. The fact that 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, each administrative domain peers with each other as part of the PSTN,
means that existing security, in the form of Personal Identification means that existing security, in the form of Personal Identification
Number (PIN) authentication (under the context of telephony infras- Number (PIN) authentication (under the context of telephony infras-
skipping to change at page 22, line 23 skipping to change at page 19, line 46
SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG
* * (SS7) * (SIP) * (SIP) * (SIP) * * * (SS7) * (SIP) * (SIP) * (SIP) *
******* *************** ************** ******* *************** **************
SW - Telco Switch SW - Telco Switch
SG - Signaling Gateway SG - Signaling Gateway
Figure 2 Figure 2
Given multiple IP domains, and the presumption that SLAs relating to Given multiple IP domains, and the presumption that SLAs relating to
IEPS traffic may exist between them, the need for something like ETS traffic may exist between them, the need for something like
diff-serv grows with respect to being able to distinguish the emer- diff-serv grows with respect to being able to distinguish the emer-
gency related traffic from other types of traffic. In addition, IP gency related traffic from other types of traffic. In addition, IP
^L
security becomes more important between domains in order to ensure security becomes more important between domains in order to ensure
that the act of distinguishing IEPS-type traffic is indeed valid for that the act of distinguishing ETS-type traffic is indeed valid for
the given source. the given source.
We conclude this section by mentioning a complimentary work in pro- We conclude this section by mentioning a complimentary work in pro-
gress in providing ISUP transparency across SS7-SIP interworking gress in providing ISUP transparency across SS7-SIP interworking
[37]. The objective of this effort is to access services in the SIP [37]. The objective of this effort is to access services in the SIP
network and yet maintain transparency of end-to-end PSTN services. network and yet maintain transparency of end-to-end PSTN services.
Not all services are mapped (as per the design goals of [37], so we Not all services are mapped (as per the design goals of [37], so we
anticipate the need for an additional document to specify the mapping anticipate the need for an additional document to specify the mapping
between new SIP labels and existing PSTN code points like NS/EP and between new SIP labels and existing PSTN code points like NS/EP and
MLPP. MLPP.
skipping to change at page 23, line 33 skipping to change at page 21, line 4
6 Baker, F., et. al., "Aggregation of RSVP for IPv4 and IPv6 6 Baker, F., et. al., "Aggregation of RSVP for IPv4 and IPv6
Reservations", Proposed Standard, RFC 3175, September 2001. Reservations", Proposed Standard, RFC 3175, September 2001.
7 Berger, L, et. al., "RSVP Refresh Overhead Reduction Extensions", 7 Berger, L, et. al., "RSVP Refresh Overhead Reduction Extensions",
Proposed Standard, RFC 2961, April, 2001. Proposed Standard, RFC 2961, April, 2001.
8 Blake, S., et. al., "An Architecture for Differentiated 8 Blake, S., et. al., "An Architecture for Differentiated
Service", Proposed Standard, RFC 2475, Dec. 1998. Service", Proposed Standard, RFC 2475, Dec. 1998.
9 Faucheur, F., et. al., "MPLS Support of Differentiated Services", 9 Faucheur, F., et. al., "MPLS Support of Differentiated Services",
Standards Track, RFC 3270, May 2002.
10 Farrel, A., et. al., "Fault Tolerance for LDP and CR-LDP", ^L
Internet Draft, Work In Progress, October 2001. Standards Track, RFC 3270, May 2002.
10 Sharma, V., Hellstrand, F., “Framework for MPLS-Based Recovery”,
11 Postel, J., "Simple Mail Transfer Protocol", Standard, RFC 821, 11 Postel, J., "Simple Mail Transfer Protocol", Standard, RFC 821,
August 1982. August 1982.
12 Handley, M., et. al., "SIP: Session Initiation Protocol", 12 Handley, M., et. al., "SIP: Session Initiation Protocol",
Proposed Standard, RFC 2543, March 1999. Proposed Standard, RFC 2543, March 1999.
13 ANSI, "Signaling System No. 7(SS7) _ High Probability of 13 ANSI, "Signaling System No. 7(SS7) _ High Probability of
Completion (HPC) Network Capability_, ANSI T1.631, 1993. Completion (HPC) Network Capability_, ANSI T1.631-1993, (R1999).
14 Robust Audio Tool (RAT): 14 Robust Audio Tool (RAT):
http://www-mice.cs.ucl.ac.uk/multimedia/software/rat http://www-mice.cs.ucl.ac.uk/multimedia/software/rat
15 Polk, J., Schulzrinne, H, "SIP Communications Resource Priority 15 Schulzrinne, H, "Requirements for Resource Priority Mechanisms for
Header", Internet Draft, Work In Progress, December, 2001. the Session Initiation Protocol", Internet Draft, Work In Pro-
gress,
December, 2001.
16 Nichols, K., et. al.,"Definition of the Differentiated Services 16 Nichols, K., et. al.,"Definition of the Differentiated Services
Field (DS Field) in the Ipv4 and Ipv6 Headers", Proposed Field (DS Field) in the Ipv4 and Ipv6 Headers", Proposed
Standard, RFC 2474, December 1998. Standard, RFC 2474, December 1998.
17 Durham, D., "The COPS (Common Open Policy Service) Protocol", 17 Durham, D., "The COPS (Common Open Policy Service) Protocol",
Proposed Standard, RFC 2748, Jan 2000. Proposed Standard, RFC 2748, Jan 2000.
18 ITU, "International Emergency Preparedness Scheme", ITU 18 ITU, "International Emergency Preparedness Scheme", ITU
Recommendation, E.106, March 2000. Recommendation, E.106, March 2000.
skipping to change at page 24, line 31 skipping to change at page 22, line 4
21 ITU, "Multi-Level Precedence and Preemption Service, ITU, 21 ITU, "Multi-Level Precedence and Preemption Service, ITU,
Recomendation, I.255.3, July, 1990. Recomendation, I.255.3, July, 1990.
22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)", 22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)",
Standards Track, RFC 3219, January 2002. Standards Track, RFC 3219, January 2002.
23 Cuervo, F., et. al, "Megaco Protocol Version 1.0", Standards 23 Cuervo, F., et. al, "Megaco Protocol Version 1.0", Standards
Track, RFC 3015, November 2000 Track, RFC 3015, November 2000
24 Perkins, C., et al., "RTP Payload for Redundant Audio Data", 24 Perkins, C., et al., "RTP Payload for Redundant Audio Data",
^L
Standards Track, RFC 2198, September, 1997 Standards Track, RFC 2198, September, 1997
25 Rosenburg, J., Schulzrinne, H., "An RTP Payload Format for 25 Rosenburg, J., Schulzrinne, H., "An RTP Payload Format for
Generic Forward Error Correction", Standards Track, RFC 2733, Generic Forward Error Correction", Standards Track, RFC 2733,
December, 1999. December, 1999.
26 ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000, 26 ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000,
2000. 2000.
27 Brown, I., "Securing IEPS over IP", White Paper, 27 Brown, I., "Securing IEPS over IP", White Paper,
skipping to change at page 25, line 16 skipping to change at page 22, line 40
32 Hardman, V., et al, "Reliable Audio for Use over the Internet", 32 Hardman, V., et al, "Reliable Audio for Use over the Internet",
Proceedings, INET'95, Aug, 1995. Proceedings, INET'95, Aug, 1995.
33 Awduche, D, et al, "Requirements for Traffic Engineering Over 33 Awduche, D, et al, "Requirements for Traffic Engineering Over
MPLS", Informational, RFC 2702, September, 1999. MPLS", Informational, RFC 2702, September, 1999.
34 Polk, J., "An Architecture for Multi-Level Precedence and 34 Polk, J., "An Architecture for Multi-Level Precedence and
Preemption over IP", Internet Draft, Work In Progress, Preemption over IP", Internet Draft, Work In Progress,
November, 2001. November, 2001.
35 "Service Class Designations for H.323 Calls", ITU Draft 35 "Service Class Designations for H.323 Calls", ITU
Recommendation H.GEF.4, September, 2001 Recommendation H.460.4, November, 2002
36 Awduche, D., et. al., "Overview and Principles of Internet Traffic 36 Awduche, D., et. al., "Overview and Principles of Internet Traffic
Engineering", Informational, RFC 3272, May 2002. Engineering", Informational, RFC 3272, May 2002.
37 Vemuri, A., Peterson, J., "SIP for Telephones (SIP-T): Context and 37 Vemuri, A., Peterson, J., "SIP for Telephones (SIP-T): Context and
Architectures", work in progress, Internet-Draft, June, 2002. Architectures", work in progress, Internet-Draft, June, 2002.
38 Polk, J., "IEPREP Topology Scenarios", Work in Progress, Internet-
Draft, December, 2002
39 Carlberg, K., Atkinson, R., "General Requirements for Emergency
Telecommunications Service", Work in Progress, Internet-Draft,
^L
January, 2003
40 Carlberg, K., Atkinson, R., "IP Telephony Requirements for
Emergency Telecommunications Service", Work In Progress, Internet-
Draft, January, 2003
8. Appendix A: Government Telephone Preference Scheme (GTPS) 8. Appendix A: Government Telephone Preference Scheme (GTPS)
This framework document uses the T1.631 and ITU IEPS standard as a This framework document uses the T1.631 and ITU IEPS standard as a
target model for defining a framework for supporting authorized emer- target model for defining a framework for supporting authorized emer-
gency related communication within the context of IP telephony. We gency related communication within the context of IP telephony. We
also use GETS as a helpful model to draw experience from. We take also use GETS as a helpful model to draw experience from. We take
this position because of the various areas that must be considered; this position because of the various areas that must be considered;
from the application layer to the (inter)network layer, in addition from the application layer to the (inter)network layer, in addition
to policy, security (authorized access), and traffic engineering. to policy, security (authorized access), and traffic engineering.
The U.K. has a different type of authorized use of telephony services The U.K. has a different type of authorized use of telephony services
referred to as the Government Telephone Preference Scheme (GTPS). referred to as the Government Telephone Preference Scheme (GTPS). At
This service was introduced in the 1950's at a time when loss of present, GTPS only applies to a subset of the local loop lines of
power to the PSTN due to war or natural disaster was of prime con- within the UK. The lines are divided into Categories 1, 2, and 3.
cern. If a loss of power did occur, it was felt that the critical The first two categories involve authorized personnel involved in
issue was to take action to limit phone usage by the general public emergencies such as natural disasters. Category 3 identifies the
so that power would be conserved for use by critical personnel general public. Priority marks, via C7/NUP, are used to bypass
involved in an emergency. call-gaping for a given Category. The authority to activate GTPS has
been extended to either a central or delegated authority.
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. While power loss is still fo concern, a more important
issue to the U.K. government is is the volume of switched traffic
during emergencies. And in fact the Cabinet Office is investigating
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, GTPS only applies to local loop lines of BT, Kingston,
and Cable & Wireless within the UK. The lines are divided into
Categories 1, 2, and 3. The first two categories involve authorized
personnel that are involved in emergencies such as natural disasters.
Catergory 3 identifes the general public.
Unlike the roaming ability of GETS users, GTPS associates preference
with an originating line. This simplifies the process of determining
who is allowed outbound phone service, but it is also quite restric-
tive in its usage. Hence, individuals that need 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 (calls the emergency services operator) can be
made.
An updated version of GTPS has been 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. Exchanges belonging to other licensed operators (i.e.,
not BT, Kingston, or C&W) are not so equiped and will only tran-
sparently pass on "priority" marks, without affecting their own use
of call-gapping. The authority to activate GTPS has been extended to
either a central or delegated authority.
8.1. GTPS and the Framework Document 8.1. GTPS and the Framework Document
The design of the current GTPS, with its designation of preference The design of the current GTPS, with its designation of preference
based on physical static devices, precludes the need for several based on physical static devices, precludes the need for several
aspects presented in this document. However, one component that can aspects presented in this document. However, one component that can
have a direct correlation is the labeling capability of the proposed have a direct correlation is the labeling capability of the proposed
Resource Priority extension to SIP. In the case of GTPS, one simply Resource Priority extension to SIP. A new label mechanism for SIP
needs to define a new NameSpace that will define values for each of could allow a transparent interoperation between IP telephony and the
its three Categories of users. These new labels will then allow a U.K. PSTN that supports GTPS.
more transparant interoperation between IP telephony using SIP and
the U.K. PSTN that supports GTPS. However, a strong possibility
exists that the IETF will discourage the registration of NameSpaces
attributed to specific organizations or geo-political boundaries. In
this case, the private definition of a NameSpace (one that is not
registered with IANA) may need to be used by systems like 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 9. Appendix B: Related Standards Work
The process of defining various labels to distinguish calls has been, The process of defining various labels to distinguish calls has been,
and continues to be, pursued in other standards groups. As mentioned 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 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 SS7 ISUP Initial Address Message. This single label or value is
^L
referred to as the National Security and Emergency Preparedness referred to as the National Security and Emergency Preparedness
(NS/EP) indicator and is part of the T1.631 standard. The following (NS/EP) indicator and is part of the T1.631 standard. The following
subsections presents a snap shot of parallel on-going efforts in subsections presents a snap shot of parallel on-going efforts in
various standards groups. various standards groups.
It is important to note that the recent activity in other groups have 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 gravitated to defining 5 labels or levels of priority. The impact of
this approach is minimal in relation to this IEPS framework document this approach is minimal in relation to this ETS framework document
because it simply generates a requirement to define and register with because it simply generates a need to define a set of corresponding
IANA a new NameSpace in the Resource-Priority header of SIP. labels for the resource priority header of SIP.
9.1. Study Group 16 (ITU) 9.1. Study Group 16 (ITU)
Study Group 16 (SG16) of the ITU is responsible for studies relating Study Group 16 (SG16) of the ITU is responsible for studies relating
to multimedia service definition and multimedia systems, including to multimedia service definition and multimedia systems, including
protocols and signal processing. protocols and signal processing.
A draft contribution [35] has been introduced into this group that A contribution [35] has been accepted by this group that adds a
would add a Priority Class parameter to the call establishment mes- Priority Class parameter to the call establishment messages of H.323.
sages of H.323. This class is further divided into two parts; one This class is further divided into two parts; one for Priority Value
for Priority Value and the other is a Priority Extension for indicat- and the other is a Priority Extension for indicating subclasses. It
ing subclasses. It is this former part that roughly corresponds to is this former part that roughly corresponds to the labels tran-
the labels transported via the Resource Priority field for SIP [15]. sported via the Resource Priority field for SIP [15].
The draft recommendation advocates defining PriorityClass information The draft recommendation advocates defining PriorityClass information
that would be carried in the GenericData parameter in the H323-UU-PDU that would be carried in the GenericData parameter in the H323-UU-PDU
or RAS messages. The GenericData parameter contains Priori- or RAS messages. The GenericData parameter contains Priori-
tyClassGenericData. The PriorityClassInfo of the PriorityClassGener- tyClassGenericData. The PriorityClassInfo of the PriorityClassGener-
icData contains the Priority and Priority Extension fields. icData contains the Priority and Priority Extension fields.
At present, 5 levels have been defined for the Priority Value part of At present, 5 levels have been defined for the Priority Value part of
the Priority Class parameter: Low, Normal, High, Emergency-Public, the Priority Class parameter: Low, Normal, High, Emergency-Public,
Emergency-Authorized. An additional 8-bit priority extension has been Emergency-Authorized. An additional 8-bit priority extension has been
skipping to change at page 28, line 16 skipping to change at page 25, line 4
ServiceClassInfo ::= SEQUENCE ServiceClassInfo ::= SEQUENCE
{ {
priority CHOICE priority CHOICE
{ {
emergencyAuthorized NULL, emergencyAuthorized NULL,
emergencyPublic NULL, emergencyPublic NULL,
high NULL, high NULL,
normal NULL, normal NULL,
low NULL low NULL
^L
} }
priorityExtension INTEGER (0..255) OPTIONAL; priorityExtension INTEGER (0..255) OPTIONAL;
requiredClass NULL OPTIONAL requiredClass NULL OPTIONAL
tokens SEQUENCE OF ClearToken OPTIONAL tokens SEQUENCE OF ClearToken OPTIONAL
cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL
} }
The advantage in using the GenericData parameter is that an existing The advantage in using the GenericData parameter is that an existing
parameter is used, as opposed to defining a new parameter and causing parameter is used, as opposed to defining a new parameter and causing
subsequent changes in existing H.323/H.225 documents. subsequent changes in existing H.323/H.225 documents.
skipping to change at page 29, line 9 skipping to change at page 26, line 9
University College London University College London University College London University College London
Department of Computer Science Department of Computer Science Department of Computer Science Department of Computer Science
Gower Street Gower Street Gower Street Gower Street
London, WC1E 6BT London, WC1E 6BT London, WC1E 6BT London, WC1E 6BT
United Kingdom United Kingdom United Kingdom United Kingdom
Table of Contents Table of Contents
1. Introduction ................................................... 2 1. Introduction ................................................... 2
1.1 Emergency Related Data ....................................... 3 1.1 Emergency Related Data ....................................... 3
1.1.1 Government Emergency Telecommunications Service (GETS) ..... 3 1.1.1 Government Emergency Telecommunications Service (GETS) ..... 3
1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 5 1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 4
1.2 Scope of this Document ....................................... 5 1.2 Scope of this Document ....................................... 4
2. Objective ..................................................... 7 2. Objective ..................................................... 6
3. Value Added Objective ......................................... 10 3. Value Added Objective ......................................... 9
3.1 Alternate Path Routing ....................................... 10 3.1 Alternate Path Routing ....................................... 9
3.2 End-to-End Fault Tolerance ................................... 12 3.2 End-to-End Fault Tolerance ................................... 10
4. Functional Requirements ....................................... 12 4. Protocols and Capabilities .................................... 11
4.1 Signaling & State Information ................................ 13 4.1 Signaling & State Information ................................ 11
4.1.1 SIP ........................................................ 13 4.1.1 SIP ........................................................ 12
4.1.2 Diff-Serv .................................................. 14 4.1.2 Diff-Serv .................................................. 12
4.1.3 RTP ........................................................ 16 4.1.3 RTP ........................................................ 14
4.1.4 MEGACO/H.248 ............................................... 17 4.1.4 MEGACO/H.248 ............................................... 15
4.2 Policy ....................................................... 18 4.2 Policy ....................................................... 15
4.3 Traffic Engineering .......................................... 18 4.3 Traffic Engineering .......................................... 16
4.4 Security ..................................................... 19 4.4 Security ..................................................... 17
5. Key Scenarios ................................................. 20 5. Key Scenarios ................................................. 17
6. Security Considerations ....................................... 22 6. Security Considerations ....................................... 20
7. References .................................................... 23 7. References .................................................... 20
8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 25 8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 23
8.1 GTPS and the Framework Document .............................. 26 8.1 GTPS and the Framework Document .............................. 23
9. Appendix B: Related Standards Work ............................ 27 9. Appendix B: Related Standards Work ............................ 23
9.1 Study Group 16 (ITU) ......................................... 27 9.1 Study Group 16 (ITU) ......................................... 24
10. Acknowledgments .............................................. 28 10. Acknowledgments .............................................. 25
11. Author's Addresses ........................................... 28 11. Author's Addresses ........................................... 25
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
^L
developing Internet standards in which case the procedures for copy- developing Internet standards in which case the procedures for copy-
rights defined in the Internet Standards process must be followed, or rights defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English. as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided as an This document and the information contained herein is provided as an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE. CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/