draft-ietf-ieprep-framework-04.txt   draft-ietf-ieprep-framework-05.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT Ian Brown INTERNET DRAFT Ian Brown
March 2, 2003 UCL June 19, 2003 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-04.txt> <draft-ietf-ieprep-framework-05.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 3, line 6 skipping to change at page 3, line 6
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
^L ^L
nternet Draft IEPS Framework March 2, 2003
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.
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.
skipping to change at page 4, line 51 skipping to change at page 4, line 50
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 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 some form of application layer signaling is used to explicitly estab-
lish and maintain voice data traffic. This explicit signaling capa-
bility provides the hooks from which VoIP traffic can be bridged to
^L ^L
establish and maintain voice data traffic. This explicit signaling the PSTN.
capability provides the hooks from which VoIP traffic can be bridged
to the PSTN.
An example of this distinction is when the Robust Audio Tool (RAT) 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
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
skipping to change at page 5, line 53 skipping to change at page 5, line 51
tions. In particular, we wish to avoid any temptation of trying to tions. In particular, we wish to avoid any temptation of trying to
replicate the exact capabilities of existing emergency voice service replicate the exact capabilities of existing emergency voice service
currently available in the PSTN to that of IP and the Internet. If currently available in the PSTN to that of IP and the Internet. If
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 These objectives represent a generic set of goals and desired capa-
bilities. Section 3 presents additional value added objectives,
which are viewed as useful, but not critical. Section 4 presents
^L ^L
capabilities. Section 3 presents additional value added objectives,
which are viewed as useful, but not critical. Section 4 presents
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.
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 telephony carriers with regard to dedi- agreements between ISPs and telephony carriers with regard to dedi-
cated links. cated links.
2. Objective 2. Objective
The support of ETS within IP telephony can be realized in the form of The objective of this document is to present a framework that
several primary objectives. From this set, we present protocols and describes how various protocols and capabilities (or mechanisms) can
capabilities (presented below in section 3) to be considered by be used to facilitate and support the traffic from ETS users. In
clients and providers of ETS type services. This document uses the several cases, we provide a bit of background in each area so that
IEPREP requirements of [39, 40] as a guide in specifying the objec- the reader is given some context and more indepth understanding. We
tives listed in this section. also provide some discussion on aspects about a given protocol or
capability that could be explored and potentially advanced to support
There are two underlying goals in the selection of these objectives. ETS. This exploration is not to be confused with specific solutions
One goal is to produce a design that maximizes the use of existing IP since we do not articulate exactly what must be done (e.g., a new
protocols and minimizes the set of additional specifications needed header field, or a new code point).
to support IP-telephony based ETS. Thus, with the inclusion of these
minimal augmentations, the bulk of the work in achieving ETS over an
IP network that is connected or unconnected to the Internet involves
operational issues. Examples of this would be the establishment of
Service Level Agreements (SLA) with ISPs, and/or the provisioning of
traffic engineered paths for ETS-related telephony traffic.
A second underlying goal in selecting the following objectives is to
take into account experiences from an existing emergency-type commun-
ication system (as described in section 1.1) as well as the existing
restrictions and constraints placed by some countries. In the former
case, we do not attempt to mimic the system, but rather extract
information as a reference model. With respect to constraints based
on laws or agency regulations, this would normally be considered
^L
outside of the scope of any IETF document. However, these con-
straints act as a means of determining the lowest common denominator
in specifying technical functional requirements. If such constraints
do not exist, then additional capabilities can be added to the base-
line set. This last item will be expanded upon in the description of
Objective #3 below.
The primary Objectives in support of authorized emergency calls:
1) High Probability of Call Completion
2) No loss of information when interacting with PSTN signaling
3) Distinction of ETS data traffic
4) Non-preemptive action
5) Non-ubiquitous support
6) Authenticated service
The first objective is the crux of our work because it defines our
expectations for both data and call signaling for IP telephony. As
stated, our objective is achieving a high probability that emergency
related calls (both data and signaling packets) will be forwarded
through an IP network. Specifically, we envision the relevance of
this objective during times of congestion, the context of which we
describe further below in this section. The critical word in this
objective is "probability", as opposed to assurance or guarantee --
the latter two placing a higher burden on the network. Objectives 4
and 5 listed above help us to qualify the term probability in the
context of other objectives.
The second objective involves the interaction of IP telephony signal-
ing with existing PSTN support for emergency related voice communica-
tions. As mentioned above in Section 1.2, standard T1.631 [26] speci-
fies emergency code points for SS7. Specifically, the National Secu-
rity and Emergency Preparedness (NS/EP) Calling Party Category code
point is defined for ISUP IAM messages used by SS7 [26]. Hence, when
IP providers choose to interconnect with the PSTN, it is our objec-
tive that this interaction between the PSTN and IP telephony with
respect to ETS (and national indicators) is a semantically straight-
forward, reversible mapping of comparable code points.
The third objective focuses on the ability to distinguish ETS data
packets from other types of VoIP packets. With such an ability,
transit providers can more easily ensure that pre-existing service
level agreements relating to ETS are adhered to. Note that we do not
assume that the actions taken to distinguish ETS type packets are
easy. Nor, in this section, do we state the form of this distinc-
tion. We simply present the objective of identifying flows that
relate to IEPS versus others that traverse a transit network.
^L
At an abstract level, the fourth objective pertains to the actions
taken when an IP telephony call, via a signaling protocol such as
SIP, cannot be forwarded because the network is experiencing a form
of congestion. We state this in general terms because of two rea-
sons: a) there may exist applications other than SIP, like H.248,
used for call establishment, and b) congestion may come in several
forms. For example, congestion may exist at the IP packet layer with
respect to queues being filled to their configured limit. Congestion
may also arise from resource allocation (i.e., QoS) attributed per
call or aggregated sets of calls. In this latter case, while there
may exist resources to forward the packets, a stateful signaling
server may have reached its configured limit as to how many telephony
calls it will support while retaining toll-quality service per call.
Typically, one terms this form of congestion as call blocking. Note
that we do not address the case when congestion occurs at the bit
level below that of IP, due to the position that it is outside the
scope of IP and the IETF.
So, given the existence of congestion in its various forms, our
objective is to support ETS-related IP telephony call signaling and
data traffic via non-preemptive actions taken by the network. More
specifically, we associate this objective in the context of IP
telephony acting as part of the Public Telephone Network (PTN).
This, as opposed to the use of IP telephony within a private or stub
network. In section 5 below, we expand on this through the descrip-
tion of two distinct scenarios of IP telephony and its operation with
IEPS and the PSTN.
It is important to mention that the fourth objective is a default
position influenced by existing laws & regulations of some countries.
Those countries, regions, or private networks not bound by these res-
trictions can remove this objective and make provisions to enforce
preemptive action. In this case, it would probably be advantageous
to deploy a signaling system similar to that proposed in [15],
wherein multiple levels of priority are defined and preemption via
admission control from SIP servers is enforced.
The fifth objective stipulates that we do not advocate the need or
expectation for ubiquitous support of ETS across all administrative
domains of the Internet. While it would be desirable to have ubiqui-
tous support, we feel the reliance of such a requirement would doom
even the contemplation of supporting ETS by the IETF and the expected
entities (e.g., ISPs and vendors) involved in its deployment.
We use the existing GETS service in the U.S. as an existing example
in which emergency related communications does not need to be ubiqui-
tous. As mentioned previously, the measure and amount of support
provided by the U.S. PSTN for GETS does not exist for all U.S. IXCs
^L
nor LECs. Given the fact that GETS still works within this context,
it is our objective to follow this deployment model such that we can
accomplish the first objective listed above -- a higher probability
of call completion than that of normal IP telephony call traffic.
Our final objective is that only authorized users may use the ser-
vices outlined in this framework. GETS users are authenticated using
a PIN provided to the telephony carrier, which signals authentication
to subsequent networks via the HPC class mark. In an IP network, the
authentication center will need to securely signal back to the IP
ingress point that a given user is authorized to send ETS related
flows. Similarly, transit networks that chose to support ETS SLAs
must securely interchange authorized ETS traffic. In both cases,
IPSec authentication transforms may be used to protect this traffic.
This is entirely separate from end-to-end IPSec protection of user
traffic, which will be configured by users. IP-PSTN gateways must
also be able to securely signal ETS authorization for a given flow.
As these gateways are likely to act as SIP servers, we further con-
sider the use of SIP's security functions to aid this objective.
3. Value Added Objective
This objective is viewed as being helpful in achieving a high proba-
bility of call completion. Its realization within an IP network
would be in the form of new protocols or enhancements to existing
ones. Thus, objectives listed in this section are treated as value
added -- an expectation that their existence would be beneficial, and
yet not viewed as critical to support ETS related IP telephony
traffic.
3.1. Alternate Path Routing
This objective involves the ability to discover and use a different
path to route IP telephony traffic around congestion points and thus
avoid them. Ideally, the discovery process would be accomplished in
an expedient manner (possibly even a priori to the need of its
existence). At this level, we make no assumptions as to how the
alternate path is accomplished, or even at which layer it is achieved
-- e.g., the network versus the application layer. But this kind of
capability, at least in a minimal form, would help contribute to
increasing the probability of call completion of IEPS traffic by mak-
ing use of noncongested alternate paths. We use the term "minimal
form" to emphasize the fact that care must be taken in how the system
provides alternate paths so it does not significantly contribute to
the congestion that is to be avoided (e.g., via excess
control/discovery messages).
^L
At the time that this document was written, we can identify two
work-in-progress areas in the IETF that can be helpful in providing
alternate paths for call signaling. The first is [10], which is
focused on network layer routing and describes a framework for
enhancements to the LDP specification of MPLS to help achieve fault
tolerance. This in itself does not provide alternate path routing,
but rather helps minimize loss in intradomain connectivity when MPLS
is used within a domain.
The second effort comes from the IP Telephony working group and
involves Telephony Routing over IP (TRIP). To date, a framework
document [19] has been published as an RFC which describes the
discovery and exchange of IP telephony gateway routing tables between
providers. The TRIP protocol [22] specifies application level
telephony routing regardless of the signaling protocol being used
(e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises
reachability and attributes of destinations. In its current form,
several attributes have already been defined, such as LocalPreference
and MultiExitDisc. Additional attributes can be registered with
IANA.
3.2. End-to-End Fault Tolerance 3. Considerations
This topic involves the work that has been done in trying to compen- When producing a solution, or examining existing protocols and
sate for lossy networks providing best effort service. In particu- mechanisms, there are some things that should be considered. One is
lar, we focus on the use of a) Forward Error Correction (FEC), and b) that inter-domain ETS communications should not rely on ubiquitous or
redundant transmissions that can be used to compensate for lost data even wide-spread support along the path between the end points.
packets. (Note that our aim is fault tolerance, as opposed to an Potentially, at the network layer there may exist islands of support
expectation of always achieving it). realized in the form of overlay networks. There may also be cases
where solutions may be constrained on an end-to-end basis (i.e., at
the transport or application layer). It is this diversity and possi-
bly partial support that need to be taken into account by those
designing and deploying ETS related solutions.
In the former case, additional FEC data packets are constructed from Another aspect to consider is that there are existing architectures
a set of original data packets and inserted into the end-to-end and protocols from other standards bodies that support emergency
stream. Depending on the algorithm used, these FEC packets can
reconstruct one or more of the original set that were lost by the
network. An example may be in the form of a 10:3 ratio, in which 10
original packets are used to generate three additional FEC packets.
Thus, if the network loses 30% or less number of packets, then the
FEC scheme will be able to compensate for that loss. The drawback to
this approach is that to compensate for the loss, a steady state
increase in offered load has been injected into the network. This
makes an arguement that the act of protection against loss has con-
tributed to additional pressures leading to congestion, which in turn
helps trigger packet loss. In addition, in using a ratio of 10:3,
the source (or some proxy) must "hold" all 10 packets in order to
construct the three FEC packets. This contributes to the end-to-end
delay of the packets as well as minor bursts of load in addition to
^L ^L
changes in jitter. related communications. The effort in interoperating with these sys-
tems, presumably through gateways or similar type nodes with IETF
The other form of fault tolerance we discuss involves the use of protocols, would foster a need to distinguish ETS flows from other
redundant transmissions. By this we mean the case in which an origi- flows. One reason would be the scenario of triggering ETS service
nal data packet is followed by one or more redundant packets. At from an IP network.
first glance, this would appear to be even less friendly to the net-
work than that of adding FEC packets. However, the encodings of the
redundant packets can be of a different type (or even transcoded into
a lower quality) that produce redundant data packets that are signi-
ficantly smaller than the original packet.
Two RFCs [24, 25] have been produced that define RTP payloads for FEC Finally, we take into consideration the requirements of [39, 40] in
and redundant audio data. An implementation example of a redundant discussing the protocols and mechanisms below in Secytion 4. In
audio application can be found in [14]. We note that both FEC and doing this, we do not make a one-to-one mapping of protocol discus-
redundant transmissions can be viewed as rather specific and to a sion with requirement. Rather, we make sure the discussion of Sec-
degree tangential solutions regarding packet loss and emergency com- tion 4 does not violet any of the requirements in [39,40].
munications. Hence, these topics are placed under the category of
value added objectives.
4. Protocols and Capabilities 4. Protocols and Capabilities
In this section, we take the objectives presented above and present a In this section, we take the objectives presented above and present a
set of protocols and capabilities that can be used to achieve them. set of protocols and capabilities that can be used to achieve them.
Given that the objectives are predominantly atomic in nature, the Given that the objectives are predominantly atomic in nature, the
measures used to address them are to be viewed separately with no measures used to address them are to be viewed separately with no
specific dependency upon each other as a whole. Various protocols specific dependency upon each other as a whole. Various protocols
and capabilities may be complimentary to each other, but there is no and capabilities may be complimentary to each other, but there is no
need for all to exist given different scenarios of operation, and need for all to exist given different scenarios of operation, and
that ETS support is not viewed as a ubiquitously available service. that ETS support is not viewed as a ubiquitously available service.
We divide this section 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
5) Routing
4.1. Signaling & State Information 4.1. Signaling & State Information
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.
^L
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.
skipping to change at page 12, line 51 skipping to change at page 8, line 47
means of distinguishing emergency related traffic (signaling and user means of distinguishing emergency related traffic (signaling and user
data) from other traffic. The existence of this PHB then provides a data) from other traffic. The existence of this PHB then provides a
baseline by which specific code points may be defined related to baseline by which specific code points may be defined related to
various emergency related traffic: authorized emergency sessions various emergency related traffic: authorized emergency sessions
(e.g., ETS), general public emergency calls (e.g., "911"), MLPP. (e.g., ETS), general public emergency calls (e.g., "911"), MLPP.
Aggregates would still exist with respect to the bundling of applica- Aggregates would still exist with respect to the bundling of applica-
tions per code point. Further, one would associate a forwarding tions per code point. Further, one would associate a forwarding
paradigm aimed at a low loss rate reflective of the code point paradigm aimed at a low loss rate reflective of the code point
selected. The new PHB could be in the form of a one or more code selected. The new PHB could be in the form of a one or more code
points that duplicate EF-type traffic characteristics. Policies points that duplicate EF-type traffic characteristics. Policies
would determine IF a measure of importance exists per EF-type code- would determine if a measure of importance exists per EF-type code-
^L
point. 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.
4.1.3. Variations Related to Diff-Serv and Queuing 4.1.3. Variations Related to Diff-Serv and Queuing
One variation to consider with respect to existing diff-serv work One variation to consider with respect to existing diff-serv work
would be to define a new or fifth class for the existing AF PHB. would be to define a new or fifth class for the existing AF PHB.
Unlike the other currently defined classes, this new one would be Unlike the other currently defined classes of 3 levels, this new one
based on five levels of drop precedence. This increase in the number would be based on five levels of drop precedence. This increase in
of levels would conveniently correlate to the levels of MLPP, which the number of levels would conveniently correlate to the levels of
has five types of priorities. The five levels would also correlate MLPP, which has five types of priorities. The five levels would also
to a recent effort in the Study Group 11 of the ITU to define 5 lev- correlate to a recent effort in the Study Group 11 of the ITU to
els for Emergency Telecommunications Service (ETS). Beyond these define 5 levels for Emergency Telecommunications Service (ETS).
other standardization efforts, the 5 levels would provide a higher Beyond these other standardization efforts, the 5 levels would pro-
level of variance that could be used to supercede the existing 3 lev- vide a higher level of variance that could be used to supercede the
els used in the other classes. Hence, if other non-emergency aggre- existing 3 levels used in the other classes. Hence, if other non-
gate traffic were assigned to the new class, the highest drop pre- emergency aggregate traffic were assigned to the new class, the
cedence they are assigned to is (3) -- corresponding to the other highest drop precedence they are assigned to is (3) -- corresponding
four currently defined classes. Emergency traffic would be set to to the other four currently defined classes. Emergency traffic would
(4) or (5), depending on the SLA that has been defined. be set to (4) or (5), depending on the SLA that has been defined.
Another variation to Another approach would be to make modifications Another variation to Another approach would be to make modifications
or additions to the existing AF PHB's, with their four classes and or additions to the existing AF PHBs, with their four classes and
three drop precedences per class. One could use the existing AF three drop precedences per class. One could use the existing AF PHBs
PHB's if one assumed that a relatively homogeneous set of packet if one assumed that a relatively homogeneous set of packet flows were
flows were marked with the same AF class markings (i.e., have only marked with the same AF class markings (i.e., have only TCP flows, or
TCP flows, or only UDP-voice flows, but not both, within a class). only UDP-voice flows, but not both, within a class). Then one could
Then one could allocate the lowest drop precedence to the emergency allocate the lowest drop precedence to the emergency traffic, and the
traffic, and the other two drop precedences to the rest of the other two drop precedences to the rest of the traffic.
traffic.
One original rationale for having three drop precedences was to be An original rationale for having three drop precedences was to be
able to separate TCP flows from UDP flows by different drop pre- able to separate TCP flows from UDP flows by different drop pre-
cedences, so UDP packets could be dropped more frequently than TCP cedences, so UDP packets could be dropped more frequently than TCP
^L
packets. TCP flows would reduce their sending rates while UDP likely packets. TCP flows would reduce their sending rates while UDP likely
would not, so this could be used to prevent UDP from bullying the TCP would not, so this could be used to prevent UDP from bullying the TCP
traffic. But if the design does not create a mixing of TCP and UDP, traffic. But if the design does not create a mixing of TCP and UDP,
then three drop precedences are not as necessary and one could be then three drop precedences are not as necessary and one could be
used for emergency traffic. used for emergency traffic.
To implement preferential dropping between classes of traffic, with To implement preferential dropping between classes of traffic, with
^L
one being emergency traffic, one would need to use a more advanced one being emergency traffic, one would need to use a more advanced
form of Active Queue Management (AQM). AQM would need to protect form of Active Queue Management (AQM). AQM would need to protect
emergency traffic as much as possible until most, if not all, of the emergency traffic as much as possible until most, if not all, of the
non-emergency traffic had been dropped. This would require creation non-emergency traffic had been dropped. This would require creation
of drop probabilities based on counting the number of packets in the of drop probabilities based on counting the number of packets in the
queue for each drop precedence individually. Instead, current imple- queue for each drop precedence individually. Instead, current imple-
mentations use an overall queue fill measurement to make decisions; mentations use an overall queue fill measurement to make decisions;
this might cause emergency packets to be dropped. This new from of this might cause emergency packets to be dropped. This new from of
AQM would be a Multiple Average-Multiple Threshold approach, instead AQM would be a Multiple Average-Multiple Threshold approach, instead
of the Single Average-Multiple Threshold approach used today. of the Single Average-Multiple Threshold approach used today.
So, it could be possible to use the current set of AF PHB's 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 MLPP's five levels of precedence, more emergency traffic, as with MLPPs five levels of precedence, more drop
drop precedences might also be considered. The five levels would precedences might also be considered. The five levels would also
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.
The other question with AF PHB's would be whether one should create a The other question with AF PHBs would be whether one should create a
new fifth class. This might be a useful approach, but, given the new fifth class. This might be a useful approach, but, given the
above discussion, a fifth class would only be needed if emergency above discussion, a fifth class would only be needed if emergency
traffic were considered a totally different type of traffic from a traffic were considered a totally different type of traffic from a
QoS perspective. Scheduling mechanisms like Weighted Fair Queueing QoS perspective. Scheduling mechanisms like Weighted Fair Queueing
and Class Based Queueing are used to designate a percentage of the and Class Based Queueing are used to designate a percentage of the
output link bandwidth that would be used for each class if all queues output link bandwidth that would be used for each class if all queues
were backlogged. Its purpose, therefore, it to manage the rates and were backlogged. Its purpose, therefore, it to manage the rates and
delays experienced by each class. But emergency traffic does not delays experienced by each class. But emergency traffic does not
necessarily require QoS any better or different than non-emergency necessarily require QoS any better or different than non-emergency
traffic. It just needs higher probability of completion which could traffic. It just needs higher probability of completion which could
be accomplished simply through drop precedences within a class. be accomplished simply through drop precedences within a class.
Emergency requirements are primarily related to preferential packet Emergency requirements are primarily related to preferential packet
dropping probabilities. dropping probabilities.
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 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 understandably considered a scarce resource. is relatively small, and understandably considered a scarce resource.
^L
Therefore, the possibility of a new PHB being defined for emergency Therefore, the possibility of a new PHB being defined for emergency
related traffic is at best a long term project that may or may not be related traffic is at best a long term project that may or may not be
accepted by the IETF. In the near term, we would initially recommend accepted by the IETF.
using the Assured Forwarding (AF) PHB [20] for distinguishing emer-
gency traffic from other 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, then it would be used for IP telephony data
packets. Otherwise, another AF class would be used for those data
flows.
It is critical to understand that one cannot specify an exact code In the near term, we would initially recommend using the Assured
point used for emergency related data flows because the relevance of
a code point is local to the given diff-serv domain (i.e., they are ^L
not globally unique per micro-flow or aggregate of flows). In addi- Forwarding (AF) PHB [20] for distinguishing emergency traffic from
tion, we can expect that the existence of a codepoint for emergency other types of flows. At a minimum, AF could be used for the dif-
related flows is based on the service level agreements established ferent SIP call signaling messages. If EF was also supported by the
with a given diff-serv domain. domain, then it would be used for IP telephony data packets. Other-
wise, another AF class would be used for those data flows.
It is also critical to understand that one cannot specify an exact
code point used exclusively for emergency related data flows. This
is because the relevance of a code point is local to the given diff-
serv domain (i.e., code points are not globally unique per micro-flow
or aggregate of flows).
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
skipping to change at page 16, line 4 skipping to change at page 11, line 47
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 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. One 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. One can propose a specification of a traffic as discussed in 4.1.2. One can propose a specification of a
^L
new shim layer protocol at some location above IP. Or, one 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
^L
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, 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].
skipping to change at page 17, line 4 skipping to change at page 12, line 43
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
^L
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 ETS telephony (according to the Megaco protocol), then by default the ETS telephony
data 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.
^L
4.2. Policy 4.2. Policy
One of the objectives listed in section 3 above is to treat ETS- sig- One of the objectives listed in section 3 above is to treat ETS- sig-
naling, 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
skipping to change at page 18, line 4 skipping to change at page 13, line 46
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 ETS 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 recommendations as to which operation of the network. We make no recommendations as to which
type of traffic engineering mechanism is used, but that such a system type of traffic engineering mechanism is used, but that such a system
exists in some form and can distinguish and support ETS signaling exists in some form and can distinguish and support ETS signaling
and/or data traffic. We recommend a review of [36] by clients and and/or data traffic. We recommend a review of [36] by clients and
prospective providers of ETS service, which gives an overview and a prospective providers of ETS service, which gives an overview and a
^L
set of principles of 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 heightened 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
permit a quasi-circuit switching capability to be superimposed on the permit a quasi-circuit switching capability to be superimposed on the
current Internet routing model [33]. current Internet routing model [33].
^L
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.
As a counter example of using a specific protocol to achieve traffic
engineering, [41] presents an example by one ISP relying on a high
amount of overprovisioning within its core to satisfy potentially
dramatic spikes or bursts of traffic load. In this approach, any
configuring of queues for specific customers (neighbors) to support
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 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
probability of call completion as the general public. It is probability of call completion as the general public. It is
expected, and encouraged, that ETS related SLAs will have a limit expected, and encouraged, that ETS related SLAs will have a limit
with respect to the amount of traffic distinguished as being emer- with respect to the amount of traffic distinguished as being emer-
gency related, and initiated by an authorized user. gency related, and initiated by an authorized user.
4.4. Security 4.4. Security
skipping to change at page 19, line 4 skipping to change at page 14, line 52
As flows traverse more than one IP network, domains whose peering As flows traverse more than one IP network, domains whose peering
agreements include ETS support must have the means to securely signal 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- 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 ETS traffic that may pass between the measures to limit the amount of ETS traffic that may pass between the
two domains. The inter-domain agreement may require the originating two domains. The inter-domain agreement may require the originating
network to take responsibility for ensuring only authorized traffic network to take responsibility for ensuring only authorized traffic
is marked with ETS priority; the downstream domain may still perform is marked with ETS priority; the downstream domain may still perform
redundant conditioning to prevent the propagation of theft and denial redundant conditioning to prevent the propagation of theft and denial
of service attacks. Security may be provided between ingress and of service attacks. Security may be provided between ingress and
egress gateways or IP endpoints using IPSec or SIP security
^L ^L
egress gateways or IP endpoints using IPSec or SIP security func- 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. These authentication procedures may occur at the tion procedures. These authentication procedures may occur at the
link or network layers, but are entirely at the discretion of the link or network layers, but are entirely at the discretion of the
ingress network. That network must decide how often it should update ingress 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.
4.5. Alternate Path Routing
This subject involves the ability to discover and use a different
path to route IP telephony traffic around congestion points and thus
avoid them. Ideally, the discovery process would be accomplished in
an expedient manner (possibly even a priori to the need of its
existence). At this level, we make no assumptions as to how the
alternate path is accomplished, or even at which layer it is achieved
-- e.g., the network versus the application layer. But this kind of
capability, at least in a minimal form, would help contribute to
increasing the probability of ETS call completion by making use of
noncongested alternate paths. We use the term "minimal form" to
emphasize the fact that care must be taken in how the system provides
alternate paths so it does not significantly contribute to the
congestion that is to be avoided (e.g., via excess control/discovery
messages).
At the time that this document was written, we can identify two areas
in the IETF that can be helpful in providing alternate paths for call
signaling. The first is [10], which is focused on network layer
routing and describes a framework for enhancements to the LDP specif-
ication of MPLS to help achieve fault tolerance. This in itself does
not provide alternate path routing, but rather helps minimize loss in
intradomain connectivity when MPLS is used within a domain.
The second effort comes from the IP Telephony working group and
involves Telephony Routing over IP (TRIP). To date, a framework
document [19] has been published as an RFC which describes the
discovery and exchange of IP telephony gateway routing tables between
providers. The TRIP protocol [22] specifies application level
telephony routing regardless of the signaling protocol being used
(e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises
reachability and attributes of destinations. In its current form,
several attributes have already been defined, such as LocalPreference
and MultiExitDisc. Additional attributes can be registered with
IANA.
^L
Inter-domain routing is not an area that should be considered in
terms of alternate path routing support for ETS. The Border Gateway
Protocol is currently strained in meetings its existing requirements,
and thus adding additional features that would generate an increase
in advertised routes will not be well received by the IETF. Refer to
[42] for a commentary on Inter-Domain routing.
4.6. End-to-End Fault Tolerance
This topic involves the work that has been done in trying to compen-
sate for lossy networks providing best effort service. In particu-
lar, we focus on the use of a) Forward Error Correction (FEC), and b)
redundant transmissions that can be used to compensate for lost data
packets. (Note that our aim is fault tolerance, as opposed to an
expectation of always achieving it).
In the former case, additional FEC data packets are constructed from
a set of original data packets and inserted into the end-to-end
stream. Depending on the algorithm used, these FEC packets can
reconstruct one or more of the original set that were lost by the
network. An example may be in the form of a 10:3 ratio, in which 10
original packets are used to generate three additional FEC packets.
Thus, if the network loses 30% or less number of packets, then the
FEC scheme will be able to compensate for that loss. The drawback to
this approach is that to compensate for the loss, a steady state
increase in offered load has been injected into the network. This
makes an arguement that the act of protection against loss has con-
tributed to additional pressures leading to congestion, which in turn
helps trigger packet loss. In addition, in using a ratio of 10:3,
the source (or some proxy) must "hold" all 10 packets in order to
construct the three FEC packets. This contributes to the end-to-end
delay of the packets as well as minor bursts of load in addition to
changes in jitter.
The other form of fault tolerance we discuss involves the use of
redundant transmissions. By this we mean the case in which an origi-
nal data packet is followed by one or more redundant packets. At
first glance, this would appear to be even less friendly to the net-
work than that of adding FEC packets. However, the encodings of the
redundant packets can be of a different type (or even transcoded into
a lower quality) that produce redundant data packets that are signi-
ficantly smaller than the original packet.
Two RFCs [24, 25] have been produced that define RTP payloads for FEC
and redundant audio data. An implementation example of a redundant
audio application can be found in [14]. We note that both FEC and
redundant transmissions can be viewed as rather specific and to a
^L
degree tangential solutions regarding packet loss and emergency com-
munications. Hence, these topics are placed under the category of
value added objectives.
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 imply a unique set of functional requirements that each of which can imply 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
is a signaling & data interaction between the PSTN and the IP network is a signaling & data interaction between the PSTN and the IP network
skipping to change at page 20, line 4 skipping to change at page 17, line 45
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.
In this example, we show two types of telephony carriers. One is the In this example, we show two types of telephony carriers. One is the
legacy carrier, whose infrastructure retains the classic switching legacy carrier, whose infrastructure retains the classic switching
architecture attributed to the PSTN. The other is the next genera- architecture attributed to the PSTN. The other is the next genera-
tion carrier, which uses a data network (e.g., IP) as its core tion carrier, which uses a data network (e.g., IP) as its core
infrastructure, and Signaling Gateways at its edges. These gateways infrastructure, and Signaling Gateways at its edges. These gateways
"speak" SS7 externally with peering carriers, and another protocol "speak" SS7 externally with peering carriers, and another protocol
^L
(e.g., SIP) internally, which rides on top of the IP infrastructure. (e.g., SIP) internally, which rides on top of the IP infrastructure.
^L
Legacy Next Generation Next Generation Legacy Next Generation Next Generation
Carrier Carrier Carrier Carrier Carrier Carrier
******* *************** ************** ******* *************** **************
* * * * ISUP * * * * * * ISUP * *
SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG
* * (SS7) * (SIP) * (SS7) * (SIP) * * * (SS7) * (SIP) * (SS7) * (SIP) *
******* *************** ************** ******* *************** **************
SW - Telco Switch SW - Telco Switch
SG - Signaling Gateway SG - Signaling Gateway
skipping to change at page 22, line 27 skipping to change at page 20, line 27
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. 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
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, (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
15 Schulzrinne, H, "Requirements for Resource Priority Mechanisms for 15 Schulzrinne, H, "Requirements for Resource Priority Mechanisms for
the Session Initiation Protocol", Internet Draft, Work In Pro- the Session Initiation Protocol", Informational, RFC 3487,
gress, February 2003
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.
^L
18 ITU, "International Emergency Preparedness Scheme", ITU 18 ITU, "International Emergency Preparedness Scheme", ITU
^L
Recommendation, E.106, March 2000. Recommendation, E.106, March 2000.
19 Rosenburg, J., Schulzrinne, H., "A Framework for Telephony Routing 19 Rosenburg, J., Schulzrinne, H., "A Framework for Telephony Routing
Over IP", Informational, RFC 2871, June 2000 Over IP", Informational, RFC 2871, June 2000
20 Heinanen. et. al, "Assured Forwarding PHB Group", Proposed 20 Heinanen. et. al, "Assured Forwarding PHB Group", Proposed
Standard, RFC 2597, June 1999 Standard, RFC 2597, June 1999
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.
skipping to change at page 24, line 17 skipping to change at page 22, line 17
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 35 "Service Class Designations for H.323 Calls", ITU
Recommendation H.460.4, November, 2002 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", Best Current Practice, RFC 3372, September 2002
38 Polk, J., “IEPREP Topology Scenarios”, Work in Progress, Internet- 38 Polk, J., "IEPREP Telephony Topology Terminology", Informational,
Draft, December, 2002 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", Work in Progress, Internet-Draft,
January, 2003 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", Work In Progress, Internet-
Draft, January, 2003 Draft, January, 2003
41 Meyers, D., "Some Thoughts on CoS and Backbone Networks"
http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf
IETF Presentation: IEPREP, Dec, 2002
42 Huston, G., "Commentary on Inter-Domain Routing In the Internet",
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-
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). At referred to as the Government Telephone Preference Scheme (GTPS). At
present, GTPS only applies to a subset of the local loop lines of present, GTPS only applies to a subset of the local loop lines of
within the UK. The lines are divided into Categories 1, 2, and 3. within the UK. The lines are divided into Categories 1, 2, and 3.
^L
The first two categories involve authorized personnel involved in The first two categories involve authorized personnel involved in
emergencies such as natural disasters. Category 3 identifies the emergencies such as natural disasters. Category 3 identifies the
general public. Priority marks, via C7/NUP, are used to bypass general public. Priority marks, via C7/NUP, are used to bypass
call-gaping for a given Category. The authority to activate GTPS has call-gaping for a given Category. The authority to activate GTPS has
been extended to either a central or delegated authority. been extended to either a central or delegated authority.
^L
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. 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.
skipping to change at page 25, line 44 skipping to change at page 23, line 49
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 contribution [35] has been accepted by this group that adds a A contribution [35] has been accepted by this group that adds a
Priority Class parameter to the call establishment messages of H.323. Priority Class parameter to the call establishment messages of H.323.
This class is further divided into two parts; one for Priority Value This class is further divided into two parts; one for Priority Value
and the other is a Priority Extension for indicating subclasses. It and the other is a Priority Extension for indicating subclasses. It
is this former part that roughly corresponds to the labels tran- is this former part that roughly corresponds to the labels
sported via the Resource Priority field for SIP [15].
^L
transported 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.
^L
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
defined to provide for subclasses of service at each priority. defined to provide for subclasses of service at each priority.
The suggested ASN.1 definition of the service class is the following: The suggested ASN.1 definition of the service class is the following:
ServiceClassInfo ::= SEQUENCE ServiceClassInfo ::= SEQUENCE
{ {
priority CHOICE priority CHOICE
skipping to change at page 26, line 42 skipping to change at page 25, line 5
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, as well
as those comments received from the IEPS and IEPREP mailing lists. as those comments received from the IEPS and IEPREP mailing lists.
Additional thanks to Peter Walker of Oftel for private discussions on Additional thanks to Peter Walker of Oftel for private discussions on
the operation of GTPS, and Gary Thom on clarifications of the SG16 the operation of GTPS, and Gary Thom on clarifications of the SG16
draft contribution. draft contribution.
^L
11. Author's Addresses 11. Author's Addresses
Ken Carlberg Ian Brown Ken Carlberg Ian Brown
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
^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 ^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) ..... 4 1.1.1 Government Emergency Telecommunications Service (GETS) ..... 4
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. Value Added Objective ......................................... 9 3. Considerations ................................................ 6
3.1 Alternate Path Routing ....................................... 9 4. Protocols and Capabilities .................................... 7
3.2 End-to-End Fault Tolerance ................................... 10 4.1 Signaling & State Information ................................ 7
4. Protocols and Capabilities .................................... 11 4.1.1 SIP ........................................................ 8
4.1 Signaling & State Information ................................ 11 4.1.2 Diff-Serv .................................................. 8
4.1.1 SIP ........................................................ 12 4.1.3 Variations Related to Diff-Serv and Queuing ................ 9
4.1.2 Diff-Serv .................................................. 12 4.1.4 RTP ........................................................ 11
4.1.3 Variations Related to Diff-Serv and Queuing ................ 13 4.1.5 MEGACO/H.248 ............................................... 12
4.1.4 RTP ........................................................ 15 4.2 Policy ....................................................... 13
4.1.5 MEGACO/H.248 ............................................... 16 4.3 Traffic Engineering .......................................... 13
4.2 Policy ....................................................... 17 4.4 Security ..................................................... 14
4.3 Traffic Engineering .......................................... 17 4.5 Alternate Path Routing ....................................... 15
4.4 Security ..................................................... 18 4.6 End-to-End Fault Tolerance ................................... 16
5. Key Scenarios ................................................. 19 5. Key Scenarios ................................................. 17
6. Security Considerations ....................................... 21 6. Security Considerations ....................................... 19
7. References .................................................... 21 7. References .................................................... 19
8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 24 8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 22
8.1 GTPS and the Framework Document .............................. 25 8.1 GTPS and the Framework Document .............................. 23
9. Appendix B: Related Standards Work ............................ 25 9. Appendix B: Related Standards Work ............................ 23
9.1 Study Group 16 (ITU) ......................................... 25 9.1 Study Group 16 (ITU) ......................................... 23
10. Acknowledgments .............................................. 26 10. Acknowledgments .............................................. 24
11. Author's Addresses ........................................... 26 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 2003. All Rights Reserved. This
This document and translations of it may be copied and furnished to document and translations of it may be copied and furnished to oth-
others, and derivative works that comment on or otherwise explain it ers, and derivative works that comment on or otherwise explain it or
or assist in its implementation may be prepared, copied, published assist in its implementation may be prepared, copied, published and
and distributed, in whole or in part, without restriction of any distributed, in whole or in part, without restriction of any kind,
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 ^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.
 End of changes. 

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