draft-ietf-ieprep-framework-07.txt   draft-ietf-ieprep-framework-08.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
December 1, 2003 Ian Brown February 5, 2004 Ian Brown
UCL UCL
Cory Beard Cory Beard
UMKC UMKC
Framework for Supporting ETS in IP Telephony Framework for Supporting ETS in IP Telephony
<draft-ietf-ieprep-framework-07.txt> <draft-ietf-ieprep-framework-08.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 2, line 4 skipping to change at page 2, line 4
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 Emergency authorized emergency service, in line with the Emergency
Telecommunications Service (ETS), should be realized within today's Telecommunications Service (ETS), should be realized within today's
IP architecture and service models. From these objectives, we IP architecture and service models. From these objectives, we
present a corresponding set of protocols and capabilities, 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
^L
service in the PSTN, contribute to a constrained solution space. service in the PSTN, contribute to a constrained solution space.
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, implies the default service model. Best Effort, in general terms, implies
that the network will attempt to forward traffic to the destination that the network will attempt to forward traffic to the destination
skipping to change at page 3, line 4 skipping to change at page 3, line 4
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
^L
aggregated treatment of data. aggregated treatment of data.
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
skipping to change at page 3, line 34 skipping to change at page 3, line 32
failures for MPLS [10]. failures for MPLS [10].
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 [11] has defined a priority field for SMTP, but it is only for map-
denoting "priority", there has not been a previous IETF standards ping with X.400 and is not meant for general usage. SIP [12] has an
based effort to state or define what this distinction means with embedded field denoting "priority", but it is only targeted towards
respect to the underlying network or the end-to-end applications and the end-user and is not menat not provide indication to the underly-
how it should be supported at any layer. Given the emergence of IP ing network or end-to-end applications.
telephony, a natural inclusion of its service is an ability to sup-
port existing emergency related services. Typically, one associates Given the emergence of IP telephony, a natural inclusion of its ser-
emergency calls with "911" telephone service in the U.S., or "999" in vice is an ability to support existing emergency related services.
the U.K. -- both of which are attributed to national boundaries and Typically, one associates emergency calls with "911" telephone ser-
accessible by the general public. Outside of this exists emergency vice in the U.S., or "999" in the U.K. -- both of which are attri-
telephone services that involved authorized usage, as described in buted to national boundaries and accessible by the general public.
the following subsection. Outside of this exists emergency telephone services that involved
authorized usage, as described in the following subsection.
1.1.1. Government Emergency Telecommunications Service (GETS) 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] and now established by the White House under an executive order [30] and now
^L
a part of the Department of Homeland Security . Unlike "911", it is a part of the Department of Homeland Security . Unlike "911", it is
only accessible by authorized individuals. The majority of these only accessible by authorized individuals. The majority of these
individuals are from various government agencies like the Department individuals are from various government agencies like the Department
of Transportation, NASA, the Department of Defense, and the Federal of Transportation, NASA, the Department of Defense, and the Federal
Emergency Management Agency (to name but a few). In addition, a Emergency Management Agency (to name but a few). In addition, a
select set of individuals from private industry (telecommunications select set of individuals from private industry (telecommunications
companies, utilities, etc.) that are involved in criticial infras- companies, utilities, etc.) that are involved in criticial infras-
tructure recovery operations are also provided access to GETS. tructure recovery operations are also provided access to GETS.
The purpose of GETS is to achieve a high probability that phone ser- The purpose of GETS is to achieve a high probability that phone ser-
skipping to change at page 4, line 51 skipping to change at page 5, line 4
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 ETS 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) [14] begins sending VoIP packets to a unicast (or multicast) destina-
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
destination. RAT does not use explicit signaling like SIP to estab- the target destination. On the other hand, "SIP phones" are host
lish an end-to-end call between two users. It simply sends data devices that use a signaling protocol to establish a call before
packets to the target destination. On the other hand, "SIP phones" sending data towards the destination.
are host devices that use a signaling protocol to establish a call
before sending data towards the destination.
One other aspect we should probably assume exists with IP Telephony 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 argument that there is a maximum packet loss and delay for makes an argument 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
lower, a 15-20% drop rate can be experienced and still considered lower, a 15-20% drop rate can be experienced and still considered
acceptable. [32] discusses the same topic and makes an arguement acceptable. [32] discusses the same topic and makes an arguement
that packet size plays a significant role in what users tolerate as that packet size plays a significant role in what users tolerate as
"intelligible" VoIP. The larger the packet, correlating to longer "intelligible" VoIP. The larger the packet, correlating to longer
skipping to change at page 6, line 4 skipping to change at page 6, line 5
nothing else, intrinsic differences between the two communications nothing else, intrinsic differences between the two communications
architectures precludes this from happening. Note, this does not architectures precludes this from happening. Note, this does not
prevent us from borrowing design concepts or objectives from existing prevent us from borrowing design concepts or objectives from existing
systems. 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 ETS related IP telephony traffic. considered important in supporting ETS related IP telephony traffic.
These objectives represent a generic set of goals and desired capa- These objectives represent a generic set of goals and desired capa-
bilities. Section 3 presents additional value added objectives, bilities. Section 3 presents additional value added objectives,
which are viewed as useful, but not critical. Section 4 presents which are viewed as useful, but not critical. Section 4 presents
^L
protocols and capabilities that relate or can play a role in support protocols and capabilities that relate or can play a role in support
of the objectives articulated in section 2. Finally, Section 5 of the objectives articulated in section 2. Finally, Section 5
presents two scenarios that currently exist or are being deployed in presents two scenarios that currently exist or are being deployed in
the near term over IP networks. These are not all-inclusive the near term over IP networks. These are not all-inclusive
scenarios, nor are they the only ones that can be articulated ([38] scenarios, nor are they the only ones that can be articulated ([38]
provides a more extensive discussion on the topology scenarios provides a more extensive discussion on the topology scenarios
related to IP telephony). However, these scenarios do show cases related to IP telephony). However, these scenarios do show cases
where some of the protocols discussed in section 4 apply, and where where some of the protocols discussed in section 4 apply, and where
some do not. some do not.
skipping to change at page 7, line 4 skipping to change at page 7, line 5
even wide-spread support along the path between the end points. even wide-spread support along the path between the end points.
Potentially, at the network layer there may exist islands of support Potentially, at the network layer there may exist islands of support
realized in the form of overlay networks. There may also be cases realized in the form of overlay networks. There may also be cases
where solutions may be constrained on an end-to-end basis (i.e., at where solutions may be constrained on an end-to-end basis (i.e., at
the transport or application layer). It is this diversity and possi- the transport or application layer). It is this diversity and possi-
bly partial support that need to be taken into account by those bly partial support that need to be taken into account by those
designing and deploying ETS related solutions. designing and deploying ETS related solutions.
Another aspect to consider is that there are existing architectures Another aspect to consider is that there are existing architectures
and protocols from other standards bodies that support emergency and protocols from other standards bodies that support emergency
^L
related communications. The effort in interoperating with these sys- related communications. The effort in interoperating with these sys-
tems, presumably through gateways or similar type nodes with IETF tems, presumably through gateways or similar type nodes with IETF
protocols, would foster a need to distinguish ETS flows from other protocols, would foster a need to distinguish ETS flows from other
flows. One reason would be the scenario of triggering ETS service flows. One reason would be the scenario of triggering ETS service
from an IP network. from an IP network.
Finally, we take into consideration the requirements of [39, 40] in Finally, we take into consideration the requirements of [39, 40] in
discussing the protocols and mechanisms below in Secytion 4. In discussing the protocols and mechanisms below in Secytion 4. In
doing this, we do not make a one-to-one mapping of protocol discus- doing this, we do not make a one-to-one mapping of protocol discus-
sion with requirement. Rather, we make sure the discussion of Sec- sion with requirement. Rather, we make sure the discussion of Sec-
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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 the current state of some In the following subsections, we discuss the current state of some
protocols and their use in providing support for ETS. We also dis- protocols and their use in providing support for ETS. We also dis-
cuss potential augmentations to different types of signaling and cuss potential augmentations to different types of signaling and
state information to help support the distinction of emergency state information to help support the distinction of emergency
related communications in general. related communications in general.
^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.
skipping to change at page 9, line 4 skipping to change at page 9, line 4
cedence approach of Assured Forwarding). The one caveat to this cedence approach of Assured Forwarding). The one caveat to this
statement are the set of DSCP bits set aside for experimental pur- statement are the set of DSCP bits set aside for experimental pur-
poses. But as the name implies, experimental is for internal examina- poses. But as the name implies, experimental is for internal examina-
tion and use and not for standardization. tion and use and not for standardization.
Comments Comments
-------- --------
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 has been taking a conservative approach in written, the IETF has been taking a conservative approach in
^L
specifying new PHBs. This is because the number of code points that specifying new PHBs. This is because the number of code points that
can be defined is relatively small and understandably considered a can be defined is relatively small and understandably considered a
scarce resource. Therefore, the possibility of a new PHB being scarce resource. Therefore, the possibility of a new PHB being
defined for emergency related traffic is at best a long term project defined for emergency related traffic is at best a long term project
that may or may not be accepted by the IETF. that may or may not be accepted by the IETF.
In the near term, we would initially suggest using the Assured For- In the near term, we would initially suggest using the Assured For-
warding (AF) PHB [20] for distinguishing emergency traffic from other warding (AF) PHB [20] for distinguishing emergency traffic from other
types of flows. At a minimum, AF could be used for the different SIP types of flows. At a minimum, AF could be used for the different SIP
call signaling messages. If EF was also supported by the domain, call signaling messages. If EF was also supported by the domain,
skipping to change at page 10, line 5 skipping to change at page 10, line 5
So, it could be possible to use the current set of AF PHBs if each So, it could be possible to use the current set of AF PHBs if each
class where reasonably homogenous in the traffic mix. But one might class where reasonably homogenous in the traffic mix. But one might
still have a need to be able to differentiate three drop precedences still have a need to be able to differentiate three drop precedences
just within non-emergency traffic. If so, more drop precedences just within non-emergency traffic. If so, more drop precedences
could be implemented. Also, if one wanted discrimination within could be implemented. Also, if one wanted discrimination within
emergency traffic, as with MLPPs five levels of precedence, more drop emergency traffic, as with MLPPs five levels of precedence, more drop
precedences might also be considered. The five levels would also precedences might also be considered. The five levels would also
correlate to a recent effort in the Study Group 11 of the ITU to correlate to a recent effort in the Study Group 11 of the ITU to
define 5 levels for Emergency Telecommunications Service. define 5 levels for Emergency Telecommunications Service.
^L
4.1.4. RTP 4.1.4. 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 representing a specific form of application media. The of payload representing a specific form of application media. The
designers of RTP also assumed an underlying network providing best designers of RTP also assumed an underlying network providing best
effort service. As such, RTP does not provide any mechanism to effort service. As such, RTP does not provide any mechanism to
skipping to change at page 11, line 4 skipping to change at page 11, line 4
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, these discussions centered on defining a new extention that ically, these discussions centered on defining a new extention that
contains a "classifier" field indicating the condition associated contains a "classifier" field indicating the condition associated
with the packet (e.g., authorized-emergency, emergency, normal) [29]. with the packet (e.g., authorized-emergency, emergency, normal) [29].
The rationale behind this idea was that focusing on RTP would allow The rationale behind this idea was that focusing on RTP would allow
one to rely on a point of aggregation that would apply to all pay- one to rely on a point of aggregation that would apply to all pay-
loads that it encapsulates. However, the AVT group has expressed a loads that it encapsulates. However, the AVT group has expressed a
^L
rough consensus that placing additional classifier state in the RTP rough consensus that placing additional classifier state in the RTP
header to denote the importance of one flow over another is not an header to denote the importance of one flow over another is not an
approach that they wish to advance. Objections ranging from relying approach that they wish to advance. Objections ranging from relying
on SIP to convey importance of a flow, as well as the possibility of on SIP to convey importance of a flow, as well as the possibility of
adversely affecting header compression, were expressed. There was adversely affecting header compression, were expressed. There was
also the general feeling that the extension header for RTP that acts also the general feeling that the extension header for RTP that acts
as a signal should not be used. as a signal should not be used.
4.1.5. GCP/H.248 4.1.5. GCP/H.248
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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
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 capability 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 ETS signaling and policy for non-preemptive call establishment of ETS signaling and
data. data.
^L
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 ETS related communication, then we default non-preemptive action of ETS related communication, then we
stipulate that some type of policy mechanism is in place to satisfy stipulate that some type of policy mechanism is in place to satisfy
the local policies of an SLA established for ETS type traffic. the local policies of an SLA established for ETS type traffic.
4.3. Traffic Engineering 4.3. Traffic Engineering
skipping to change at page 13, line 5 skipping to change at page 13, line 5
target QoS is done on the egress edge of the transit network. target QoS is done on the egress edge of the transit network.
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 loosely defined maximum alloca- for GETS service tend to focus on a loosely defined maximum alloca-
tion of (e.g., 1% to 10%) of calls allowed to be established through tion of (e.g., 1% to 10%) of calls allowed to be established through
a given LEC using HPC. It is expected, and encouraged, that ETS a given LEC using HPC. It is expected, and encouraged, that ETS
related SLAs of ISPs will have a limit with respect to the amount of related SLAs of ISPs will have a limit with respect to the amount of
traffic distinguished as being emergency related, and initiated by an traffic distinguished as being emergency related, and initiated by an
authorized user. authorized user.
^L
4.4. Security 4.4. Security
If ETS support moves from intra-domain PSTN and IP networks to This section provides a brief overview of the security issues raised
inter-domain end-to-end IP, authenticated service becomes more com- by ETS support.
plex to provide. Where an ETS call is carried from PSTN to PSTN via
one telephony carrier's backbone IP network, very little IP-specific
security support is required. The user authenticates themself as
usual to the network. The gateway from the PSTN connection into the
backbone IP network must be able to signal that the flow has an ETS
label. Conversely, the gateway back into the PSTN must similarly sig-
nal the call's label. A secure link between the gateways may be set
up using IPSec or SIP security functionality. If the endpoint is an
IP device, the link may be set up securely from the ingress gateway
to the end device.
As flows traverse more than one IP network, domains whose peering 4.4.1. Denial of Service
agreements include ETS support must have the means to securely signal
a given flow's ETS status. They may choose to use physical link secu-
rity and/or IPSec authentication, combined with traffic conditioning
measures to limit the amount of ETS traffic that may pass between the
two domains. The inter-domain agreement may require the originating
network to take responsibility for ensuring only authorized traffic
is marked with ETS priority; the downstream domain may still perform
redundant conditioning to prevent the propagation of theft and denial
of service attacks. Security may be provided between ingress and
egress gateways or IP endpoints using IPSec or SIP security func-
tions.
When a call originates from an IP device, the ingress network may Any network mechanism that enables a higher level of priority for a
authorize ETS traffic over that link as part of its user authentica- specific set of flows could be abused to enhance the effectiveness of
tion procedures. These authentication procedures may occur at the denial of service attacks. Priority would magnify the effects of
link or network layers, but are entirely at the discretion of the attack traffic on bandwidth availability in lower-capacity links, and
ingress network. That network must decide how often it should update increase the likelihood of it reaching its target(s). An attack could
also tie up resources such as circuits in a PSTN gateway.
Any provider deploying a priority mechanism (such as the QoS systems
described in section 4.1) must therefore carefully apply the associ-
ated access controls and security mechanisms. For example, the prior-
ity level for traffic originating from an unauthorized part of a net-
work or ingress point should be reset to normal. Users must also be
authenticated before being allowed to use a priority service (see
section 4.4.2). However, this authentication process should be light-
weight to minimise opportunities for denial of service attacks on the
authentication service itself, and ideally should include its own
anti-DoS mechanisms. Other security mechanisms may impose an overhead
that should be carefully considered to avoid creating other opportun-
ities for DoS attacks.
As mentioned in section 4.3, SLAs for ETS facilities often contain
maximum limits on the level of ETS traffic that should be prioritised
in a particular network (say 1% of the maximum network capacity).
This should also be the case in IP networks to again reduce the level
of resources that a denial of service attack can consume.
As of this writing, a typical inter-provider IP link uses 1 Gbps Eth-
ernet, OC-48 SONET/SDH, or some similar or faster technology. Also
as of this writing, it is not practical to deploy per-packet crypto-
graphic authentication on such inter-provider links, although such
authentication might well be needed to provide assurance of IP-layer
label integrity in the inter-provider scenario.
While Moore's Law will speed up cryptographic authentication, it is
unclear whether that is helpful because the speed of the typical
inter-domain link is also increasing rapidly.
4.4.2. User authorization
To prevent theft of service and reduce the opportunities for denial
of service attacks, it is essential that service providers properly
verify the authorization of a specific traffic flow before providing
it with ETS facilities.
Where an ETS call is carried from PSTN to PSTN via one telephony
carrier's backbone IP network, very little IP-specific user authori-
zation support is required. The user authenticates themself as usual
to the PSTN -- for example, using a PIN in the US GETS. The gateway
from the PSTN connection into the backbone IP network must be able to
signal that the flow has an ETS label. Conversely, the gateway back
into the PSTN must similarly signal the call's label. A secure link
between the gateways may be set up using IPSec or SIP security func-
tionality to protect the integrity of the signalling information
against attackers who have gained access to the backbone network, and
prevent such attackers placing ETS calls using the egress PSTN gate-
way. If the destination of a call is an IP device, the signalling
should be protected directly between the IP ingress gateway and the
end device.
When ETS priority is being provided to a flow within one domain, that
network must use the security features of the priority mechanism
being deployed to ensure the flow has originated from an authorized
user or process.
The access network may authorize ETS traffic over a link as part of
its user authentication procedures. These procedures may occur at the
link, network or higher layers, but are at the discretion of a single
domain network. That network must decide how often it should update
its list of authorized ETS users based on the bounds it is prepared its list of authorized ETS users based on the bounds it is prepared
to accept on traffic from recently-revoked users. to accept on traffic from recently-revoked users.
If ETS support moves from intra-domain PSTN and IP networks to
inter-domain end-to-end IP, verifying the authorization of a given
flow becomes more complex. The user's access network must verify a
user's ETS authorization if network-layer priority is to be provided
at that point. Domains whose peering agreements include ETS support
must have the means to securely signal to each other a given flow's
ETS status. They may use physical link security combined with traffic
conditioning measures to limit the amount of ETS traffic that may
pass between the two domains. The peering agreement must require the
originating network to take responsibility for ensuring that only
authorized traffic is marked with ETS priority, but the recipient
network cannot rely on this happening with 100% reliability. Both
domains should perform conditioning to prevent the propagation of
theft and denial of service attacks.
Processes using application-layer protocols such as SIP should use
the security functionality in those protocols to verify the authori-
zation of a session before allowing it to use ETS mechanisms.
4.4.3. Confidentiality and integrity
When ETS communications are being used to respond to a deliberate
attack, it is important that they cannot be altered or intercepted to
worsen the situation -- for example, by changing the orders to first
responders such as firefighters or by using knowledge of the emer-
gency response to cause further damage.
The integrity and confidentiality of such communications should
therefore be protected as far as possible using end-to-end security
protocols such as IPSec or the security functionality in SIP and
SRTP. Where communications involve other types of network such as the
PSTN, the IP side should be protected and any security functionality
available in the other network should be used.
4.5. Alternate Path Routing 4.5. Alternate Path Routing
This subject involves the ability to discover and use a different This subject 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 assumptions 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
^L
increasing the probability of ETS call completion by making use of increasing the probability of ETS call completion by making use of
noncongested alternate paths. We use the term "minimal form" to noncongested alternate paths. We use the term "minimal form" to
emphasize the fact that care must be taken in how the system provides emphasize the fact that care must be taken in how the system provides
alternate paths so it does not significantly contribute to the alternate paths so it does not significantly contribute to the
congestion that is to be avoided (e.g., via excess control/discovery congestion that is to be avoided (e.g., via excess control/discovery
messages). messages).
At the time that this document was written, we can identify two areas Routing protocols at the IP network layer, such as BGP and OSPF, con-
in the IETF that can be helpful in providing alternate paths for call tain mechanisms for determining link failure between routing peers.
signaling. The first is [10], which is focused on network layer The discovery of this failure automatically causes information to be
routing and describes a framework for enhancements to the LDP specif- propagated to other routers. The form of this information, the
ication of MPLS to help achieve fault tolerance. This in itself does extent of its propagation, and the convergence time in determining
not provide alternate path routing, but rather helps minimize loss in new routes is dependent on the routing protocol in use. In the exam-
intradomain connectivity when MPLS is used within a domain. ple of OSPF's Equal Cost Multiple Path (ECMP), the impact of link
failure is minimized because of pre-existing alternate paths to a
destination.
At the time that this document was written, we can identify two addi-
tional areas in the IETF that can be helpful in providing alternate
paths for the specific case of call signaling. The first is [10],
which is focused on network layer routing and describes a framework
for enhancements to the LDP specification of MPLS to help achieve
fault tolerance. This in itself does not provide alternate path
routing, but rather helps minimize loss in intradomain connectivity
when MPLS is used within a domain.
The second effort comes from the IP Telephony working group and 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. IANA.
Inter-domain routing is not an area that should be considered in Inter-domain routing is not an area that should be considered in
terms of alternate path routing support for ETS. The Border Gateway terms of additional alternate path routing support for ETS. The
Protocol is currently strained in meeting its existing requirements, Border Gateway Protocol is currently strained in meeting its existing
and thus adding additional features that would generate an increase requirements, and thus adding additional features that would generate
in advertised routes will not be well received by the IETF. Refer to an increase in advertised routes will not be well received by the
[42] for a commentary on Inter-Domain routing. IETF. Refer to [42] for a commentary on Inter-Domain routing.
4.6. End-to-End Fault Tolerance 4.6. 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).
In the former case, additional FEC data packets are constructed from In the former case, additional FEC data packets are constructed from
a set of original data packets and inserted into the end-to-end a set of original data packets and inserted into the end-to-end
stream. Depending on the algorithm used, these FEC packets can stream. Depending on the algorithm used, these FEC packets can
reconstruct one or more of the original set that were lost by the reconstruct one or more of the original set that were lost by the
^L
network. An example may be in the form of a 10:3 ratio, in which 10 network. An example may be in the form of a 10:3 ratio, in which 10
original packets are used to generate three additional FEC packets. original packets are used to generate three additional FEC packets.
Thus, if the network loses 30% or less number of packets, then the Thus, if the network loses 30% or less number of packets, then the
FEC scheme will be able to compensate for that loss. The drawback to FEC scheme will be able to compensate for that loss. The drawback to
this approach is that to compensate for the loss, a steady state this approach is that to compensate for the loss, a steady state
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
skipping to change at page 16, line 4 skipping to change at page 17, line 46
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
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.
Note: as stated in section 1.2, [36] provides a more extensive set of Note: as stated in section 1.2, [36] provides a more extensive set of
^L
scenarios in which IP telephony can be deployed. Our selected set 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- 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. 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
skipping to change at page 17, line 4 skipping to change at page 18, line 46
Service as the voice traffic (data and signaling) exits the IP net- Service as the voice traffic (data and signaling) exits the IP net-
work because of the existing SS7 provisioned service between work because of the existing SS7 provisioned service between
telephony carriers. Thus, the need for support of mechanisms like telephony carriers. Thus, the need for support of mechanisms like
diff-serv in the presence of overprovisioning, and an expansion of diff-serv in the presence of overprovisioning, and an expansion of
the defined set of Per-Hop Behaviors, is reduced under this scenario. the defined set of Per-Hop Behaviors, is reduced 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
^L
Number (PIN) authentication (under the context of telephony infras- Number (PIN) authentication (under the context of telephony infras-
tructure protection), is the default scope of security. We do not tructure protection), is the default scope of security. We do not
claim that the reliance on a PIN based security system is highly claim that the reliance on a PIN based security system is highly
secure or even desirable. But, we use this system as a default secure or even desirable. But, we use this system as a default
mechanism in order to avoid placing additional requirements on exist- mechanism in order to avoid placing additional requirements on
ing authorized emergency telephony systems. existing authorized emergency telephony systems.
Multiple IP Administrative Domains Multiple IP Administrative Domains
---------------------------------- ----------------------------------
We view the scenario of multiple IP administrative domains as a We view the scenario of multiple IP administrative domains as a
superset of the previous scenario. Specifically, we retain the superset of the previous scenario. Specifically, we retain the
notion that the IP telephony system peers with the existing PSTN. In notion that the IP telephony system peers with the existing PSTN. In
addition, segments addition, segments
(i.e., portions of the Internet) may exchange signaling with other IP (i.e., portions of the Internet) may exchange signaling with other IP
skipping to change at page 18, line 4 skipping to change at page 19, line 43
gency related traffic from other types of traffic. In addition, IP gency related traffic from other types of traffic. In addition, IP
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 ETS-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
^L
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.
6. Security Considerations 6. Security Considerations
Information on this topic is presented in sections 2 and 4. Information on this topic is presented in sections 2 and 4.
7. References 7. References
skipping to change at page 18, line 50 skipping to change at page 20, line 45
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. Standards Track, RFC 3270, May 2002.
10 Sharma, V., Hellstrand, F., "Framework for MPLS-Based Recovery", 10 Sharma, V., Hellstrand, F., "Framework for MPLS-Based Recovery",
Informational, RFC 3469, February 2003 Informational, RFC 3469, February 2003
11 Postel, J., "Simple Mail Transfer Protocol", Standard, RFC 821, 11 Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", Proposed Standard, RFC 2156,
^L January 1998.
August 1982.
12 Rosenberg, J., et. al., "SIP: Session Initiation Protocol", 12 Rosenberg, J., et. al., "SIP: Session Initiation Protocol",
Proposed Standard, RFC 3261, June 2002. Proposed Standard, RFC 3261, June 2002.
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, (R1999). 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
skipping to change at page 20, line 4 skipping to change at page 21, line 48
Standards Track, RFC 3525, June 2003 Standards Track, RFC 3525, June 2003
24 Perkins, C., et al., "RTP Payload for Redundant Audio Data", 24 Perkins, C., et al., "RTP Payload for Redundant Audio Data",
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,
^L
2000. 2000.
27 Brown, I., "Securing IEPS over IP", White Paper, 27 Brown, I., "Securing IEPS over IP", White Paper,
http://iepscheme.net/docs/secure_IEPS.doc http://iepscheme.net/docs/secure_IEPS.doc
28 "Description of an International Emergency Preference 28 "Description of an International Emergency Preference
Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002 Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002
29 Carlberg, K., "The Classifier Extension Header for RTP", Internet 29 Carlberg, K., "The Classifier Extension Header for RTP", Internet
Draft, Work In Progress, October 2001. Draft, Work In Progress, October 2001.
30 National Communications System: http://www.ncs.gov 30 National Communications System: http://www.ncs.gov
31 Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP", 31 Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP",
http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/, http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/,
skipping to change at page 20, line 46 skipping to change at page 22, line 39
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", Best Current Practice, RFC 3372, September 2002 Architectures", Best Current Practice, RFC 3372, September 2002
38 Polk, J., "IEPREP Telephony Topology Terminology", Informational, 38 Polk, J., "IEPREP Telephony Topology Terminology", Informational,
RFC 3523, April 2003 RFC 3523, April 2003
39 Carlberg, K., Atkinson, R., "General Requirements for Emergency 39 Carlberg, K., Atkinson, R., "General Requirements for Emergency
Telecommunications Service", Work in Progress, Internet-Draft, Telecommunications Service", Informational, RFC 3689, Feb 2004
January, 2003
40 Carlberg, K., Atkinson, R., "IP Telephony Requirements for 40 Carlberg, K., Atkinson, R., "IP Telephony Requirements for
Emergency Telecommunications Service", Work In Progress, Internet- Emergency Telecommunications Service", Informational, RFC 3690
Draft, January, 2003 Feb 2004
41 Meyers, D., "Some Thoughts on CoS and Backbone Networks" 41 Meyers, D., "Some Thoughts on CoS and Backbone Networks"
^L
http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf
IETF Presentation: IEPREP, Dec, 2002 IETF Presentation: IEPREP, Dec, 2002
42 Huston, G., "Commentary on Inter-Domain Routing In the Internet", 42 Huston, G., "Commentary on Inter-Domain Routing In the Internet",
Informational, RFC 3221, December 2001. Informational, RFC 3221, December 2001.
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-
skipping to change at page 22, line 4 skipping to change at page 23, line 41
Resource Priority extension to SIP. A new label mechanism for SIP Resource Priority extension to SIP. A new label mechanism for SIP
could allow a transparent interoperation between IP telephony and the could allow a transparent interoperation between IP telephony and the
U.K. PSTN that supports GTPS. U.K. PSTN that supports GTPS.
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 ETS framework document this approach is minimal in relation to this ETS framework document
because it simply generates a need to define a set of corresponding because it simply generates a need to define a set of corresponding
labels for the resource priority header of SIP. labels for the resource priority header of SIP.
skipping to change at page 23, line 5 skipping to change at page 24, line 41
CALL-PRIORITY {itu-t(0) recommendation(0) h(8) 460 4 version1(0)} CALL-PRIORITY {itu-t(0) recommendation(0) h(8) 460 4 version1(0)}
DEFINITIONS AUTOMATIC TAGS::= DEFINITIONS AUTOMATIC TAGS::=
BEGIN BEGIN
IMPORTS IMPORTS
ClearToken, ClearToken,
CryptoToken CryptoToken
FROM H235-SECURITY-MESSAGES; FROM H235-SECURITY-MESSAGES;
^L
CallPriorityInfo::= SEQUENCE CallPriorityInfo::= SEQUENCE
{ {
priorityValue CHOICE priorityValue CHOICE
{ {
emergencyAuthorized NULL, emergencyAuthorized NULL,
emergencyPublic NULL, emergencyPublic NULL,
high NULL, high NULL,
normal NULL, normal NULL,
}, },
priorityExtension INTEGER (0..255) OPTIONAL, priorityExtension INTEGER (0..255) OPTIONAL,
tokens SEQUENCE OF ClearToken OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL,
cryptoTokens SEQUENCE OF CryptoToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoToken OPTIONAL,
rejectReason CHOICE rejectReason CHOICE
{ {
priorityUnavailable NULL, priorityUnavailable NULL,
priorityUnauthorized NULL, priorityUnauthorized NULL,
priorityValueUnknown NULL, priorityValueUnknown NULL,
} OPTIONAL, -- Only used in CallPriorityConfirm } OPTIONAL, -- Only used in CallPriorityConfirm
} }
skipping to change at page 23, line 34 skipping to change at page 25, line 22
} OPTIONAL, -- Only used in CallPriorityConfirm } OPTIONAL, -- Only used in CallPriorityConfirm
} }
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.
10. Acknowledgments 10. Acknowledgments
The authors would like to acknowledge the helpful comments, opinions, The authors would like to acknowledge the helpful comments, opinions,
and clarifications of Stu Goldman, James Polk, Dennis Berg, as well and clarifications of Stu Goldman, James Polk, Dennis Berg, Ran
as those comments received from the IEPS and IEPREP mailing lists. Atkinson as well as those comments received from the IEPS and IEPREP
Additional thanks to Peter Walker of Oftel for private discussions on mailing lists. Additional thanks to Peter Walker of Oftel for
the operation of GTPS, and Gary Thom on clarifications of the SG16 private discussions on the operation of GTPS, and Gary Thom on cla-
draft contribution. rifications of the SG16 draft contribution.
11. Author's Addresses 11. Author's Addresses
Ken Carlberg Ian Brown Ken Carlberg Ian Brown
G11 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
^L
Cory Beard Cory Beard
University of Missouri-Kansas City University of Missouri-Kansas City
Division of Computer Science Division of Computer Science
Electrical Engineering Electrical Engineering
5100 Rockhill Road 5100 Rockhill Road
Kansas City, MO 64110-2499 Kansas City, MO 64110-2499
USA USA
BeardC@umkc.edu BeardC@umkc.edu
^L
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) ......... 4 1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 4
1.2 Scope of this Document ....................................... 4 1.2 Scope of this Document ....................................... 4
2. Objective ..................................................... 6 2. Objective ..................................................... 6
3. Considerations ................................................ 6 3. Considerations ................................................ 6
4. Protocols and Capabilities .................................... 7 4. Protocols and Capabilities .................................... 7
4.1 Signaling & State Information ................................ 7 4.1 Signaling & State Information ................................ 7
4.1.1 SIP ........................................................ 8 4.1.1 SIP ........................................................ 8
4.1.2 Diff-Serv .................................................. 8 4.1.2 Diff-Serv .................................................. 8
4.1.3 Variations Related to Diff-Serv and Queuing ................ 9 4.1.3 Variations Related to Diff-Serv and Queuing ................ 9
4.1.4 RTP ........................................................ 10 4.1.4 RTP ........................................................ 10
4.1.5 GCP/H.248 .................................................. 11 4.1.5 GCP/H.248 .................................................. 11
4.2 Policy ....................................................... 11 4.2 Policy ....................................................... 11
4.3 Traffic Engineering .......................................... 12 4.3 Traffic Engineering .......................................... 12
4.4 Security ..................................................... 13 4.4 Security ..................................................... 13
4.5 Alternate Path Routing ....................................... 13 4.4.1 Denial of Service ........................................... 13
4.6 End-to-End Fault Tolerance ................................... 14 4.4.2 User authorization .......................................... 14
5. Key Scenarios ................................................. 15 4.4.3 Confidentiality and integrity ............................... 15
6. Security Considerations ....................................... 18 4.5 Alternate Path Routing ....................................... 15
7. References .................................................... 18 4.6 End-to-End Fault Tolerance ................................... 16
8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 21 5. Key Scenarios ................................................. 17
8.1 GTPS and the Framework Document .............................. 21 6. Security Considerations ....................................... 20
9. Appendix B: Related Standards Work ............................ 21 7. References .................................................... 20
9.1 Study Group 16 (ITU) ......................................... 22 8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 23
10. Acknowledgments .............................................. 23 8.1 GTPS and the Framework Document .............................. 23
11. Author's Addresses ........................................... 23 9. Appendix B: Related Standards Work ............................ 23
9.1 Study Group 16 (ITU) ......................................... 24
10. Acknowledgments .............................................. 25
11. Author's Addresses ........................................... 25
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society 2003. All Rights Reserved. This "Copyright (C) The Internet Society 2003. All Rights Reserved. This
document and translations of it may be copied and furnished to oth- document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are 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
^L
Internet organizations, except as needed for the purpose of develop- Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English. 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
 End of changes. 

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