draft-ietf-ieprep-framework-00.txt   draft-ietf-ieprep-framework-01.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT Ian Brown INTERNET DRAFT Ian Brown
February 21, 2002 UCL May 14, 2002 UCL
Framework for Supporting IEPS in IP Telephony Framework for Supporting IEPS in IP Telephony
<draft-ietf-ieprep-framework-00.txt> <draft-ietf-ieprep-framework-01.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 15 skipping to change at page 3, line 15
treated as Best Effort and uses what resources are made available to treated as Best Effort and uses what resources are made available to
it. it.
Beyond the introduction of new services, the continued pace of addi- Beyond the introduction of new services, the continued pace of addi-
tional traffic load experienced by ISPs over the years has continued tional traffic load experienced by ISPs over the years has continued
to place a high importance for intra-domain traffic engineering. The to place a high importance for intra-domain traffic engineering. The
explosion of IETF contributions, in the form of drafts and RFCs pro- explosion of IETF contributions, in the form of drafts and RFCs pro-
duced in the area of Multi Protocol Label Switching (MPLS), exempli- duced in the area of Multi Protocol Label Switching (MPLS), exempli-
fies the interest in versatile and manageable mechanisms for intra- fies the interest in versatile and manageable mechanisms for intra-
domain traffic engineering. One interesting observation is the work domain traffic engineering. One interesting observation is the work
involved in supporting QoS related. Specifically, we refer to the involved in supporting QoS related traffic engineering. Specifically,
work in progress discussion of Proposed MPLS/DiffServ Traffic we refer to the work in progress discussion of Proposed MPLS/DiffServ
Engineering Class Types [9], and the inclusion of fault tolerance Traffic Engineering Class Types [9], and the inclusion of fault
[10]. This latter item can be viewed as being similar to "crank- tolerance [10]. This latter item can be viewed as being similar to
back", a term used to describe the means by which the Public Switched "crank-back", a term used to describe the means by which the Public
Telephone Network (PSTN) routes around congested switches. Switched Telephone Network (PSTN) routes around congested switches.
1.1. Emergency Related Data 1.1. Emergency Related Data
The evolution of the IP service model architecture has traditionally The evolution of the IP service model architecture has traditionally
centered on the type of application protocols used over a network. centered on the type of application protocols used over a network.
By this we mean that the distinction, and possible bounds on QoS, By this we mean that the distinction, and possible bounds on QoS,
usually centers on the type of application (e.g., audio video tools) usually centers on the type of application (e.g., audio video tools)
that is being referred to. that is being referred to.
While protocols like SMTP [11] and SIP [12] have embedded fields While protocols like SMTP [11] and SIP [12] have embedded fields
denoting "priority", there has not been a previous IETF standards denoting "priority", there has not been a previous IETF standards
based effort to state or define what this distinction means with based effort to state or define what this distinction means with
respect to the underlying network and how it should be supported. respect to the underlying network and how it should be supported.
Given the emergence of IP telephony, a natural inclusion of it as Given the emergence of IP telephony, a natural inclusion of it as
part of a telco carriers backbone network, or into the Internet as a part of a telco carrier's backbone network, or into the Internet as a
whole, implies the ability to support existing emergency related ser- whole, implies the ability to support existing emergency related ser-
vices. Typically, one associates emergency calls with "911" tele- vices. Typically, one associates emergency calls with "911" tele-
phone service in the U.S., or "999" in the U.K. -- both of which are phone service in the U.S., or "999" in the U.K. -- both of which are
attributed to national boundaries and accessible by the general pub- attributed to national boundaries and accessible by the general pub-
lic. Outside of this exists emergency telephone services that lic. Outside of this exists emergency telephone services that
involved authorized usage, as described in the following subsection. 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.
skipping to change at page 4, line 18 skipping to change at page 4, line 18
cial infrastructure recovery operations are also provided access to cial infrastructure recovery operations are also provided access to
GETS. GETS.
The purpose of GETS is to increase the probability that phone service The purpose of GETS is to increase the probability that phone service
will be available to selected government agency personnel in times of will be available to selected government agency personnel in times of
emergencies, such as hurricanes, earthquakes, and other disasters emergencies, such as hurricanes, earthquakes, and other disasters
that may produce a burden in the form of call blocking (i.e., conges- that may produce a burden in the form of call blocking (i.e., conges-
tion) on the U.S. Public Switched Telephone Network by the general tion) on the U.S. Public Switched Telephone Network by the general
public. public.
The key aspect is that GETS only supports a probabilistic approach to The key aspect of GETS is that it supports a probabilistic approach
call completion, as opposed to call preemption. This distinction is to call completion through priority, as opposed to guaranteed
important because emergency systems like GETS are not allowed to ter- approach through preemption. This distinction is important because
minate existing calls in order to allow a GETS call to be esta- emergency services like GETS are not allowed to tear down existing
blished. Thus, the mechanisms and specifications that comprise GETS calls (i.e., seize resources) in order to establish a GETS call. 
only focus on increasing the chances that a particular telephone call Instead, GETS increases the probability of call completion by provid-
will be established. ing an additional label used in the contention for assignment of lim-
ited resources required for the call.  Thus, the GETS features focus
on increasing the probability that a particular telephone call will
be established, but cannot guarantee call completion.
GETS is supported by Signaling System 7 (SS7) via the T1.631 protocol GETS is supported by Signaling System 7 (SS7) via the T1.631 protocol
on High Probability of Completion (HPC) network capability [13]. on High Probability of Completion (HPC) network capability [13].
This document describes the specification of a National Security and This document describes the specification of a National Security and
Emergency Preparedness (NS/EP) Calling Party Category (CPC) code Emergency Preparedness (NS/EP) Calling Party Category (CPC) code
point used for SS7 ISDN User Part (ISUP) Initial Address Message point used for SS7 ISDN User Part (ISUP) Initial Address Message
(IAM). In the presense of this code point, Local Exchange Carriers (IAM). In the presence of this code point, when a GETS call
(LEC) will attempt (if necessary and if the option is supported) to encounters a restrictive network management control that has been
route the call through alternate inter-exchange carriers (IXC) if it activated to reduce traffic overload to a congested route, the Local
cannot complete the call through the default IXC. Exchange Carriers (LECs) will provide the GETS call priority by
exempting the call from this restriction.  After receiving the exemp-
tion, if the GETS call finds all circuits busy in the route, the LEC
will provide further priority by queuing the call for the next avail-
able circuit. 
The procedure for a user (i.e., a person) establishing a GETS call is The procedure for a user (i.e., a person) establishing a GETS call is
as follows: as follows:
1) Dial a non-geographical area code number: 710-XXX-XXXX 1) Dial a non-geographical area code number: 710-XXX-XXXX
2) Dial a PIN used to authenticate the call 2) Dial a PIN used to authenticate the call
3) Dial the actual destination number to be reached 3) Dial the actual destination number to be reached
In conjunction with the above, the source LEC (where the call ori- In conjunction with the above, the source LEC (where the call ori-
ginated) attempts to establish the call through an IXC. This is done ginated) attempts to establish the call through an IXC. This is done
skipping to change at page 6, line 18 skipping to change at page 6, line 24
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
sampling rate, the lower the acceptable rate of loss. sampling rate, the lower the acceptable rate of loss.
Regardless of a definitive drop rate, it would seem that interactive Regardless of a definitive drop rate, it would seem that interactive
voice has a lower threshold of loss than other elastic applications. voice has a lower threshold of loss than other elastic applications.
This places a harder burden on the problem space of supporting VoIP This places a higher burden on the problem space of supporting VoIP
over the Internet. This problem is also further compounded when over the Internet. This problem is further compounded when toll-
toll-quality service is expected because it assumes a default service quality service is expected because it assumes a default service
model that is better than best effort. This in turn can increase the model that is better than best effort. This in turn can increase the
probability that a form of call-blocking can occur with VoIP or IP probability that a form of call-blocking can occur with VoIP or IP
telephony traffic. telephony traffic.
Beyond this, part of our motivation in writing this document is to Beyond this, part of our motivation in writing this document is to
provide a framework for ISPs and carriers so that they have an under- provide a framework for ISPs and carriers so that they have an under-
standing of objectives and accompanying functional requirements used standing of objectives and accompanying functional requirements used
to support IEPS related IP telephony traffic. In addition, we also to support IEPS related IP telephony traffic. In addition, we also
wish to provide a reference point for potential customers (users of wish to provide a reference point for potential customers (users of
IEPS) in order to constrain their expectations. In particular, we IEPS) in order to constrain their expectations. In particular, we
skipping to change at page 8, line 46 skipping to change at page 9, line 5
The third objective focuses on the ability to distinguish IEPS data The third objective focuses on the ability to distinguish IEPS data
packets from other types of VoIP packets. With such an ability, packets from other types of VoIP packets. With such an ability,
transit providers can more easily ensure that service level agree- transit providers can more easily ensure that service level agree-
ments relating to IEPS are adhered to. Note that we do not assume ments relating to IEPS are adhered to. Note that we do not assume
that the actions taken to distinguish IEPS type packets is easy. that the actions taken to distinguish IEPS type packets is easy.
Nor, in this section, do we state the form of this distinction. We Nor, in this section, do we state the form of this distinction. We
simply present the objective of identifying flows that relate to IEPS simply present the objective of identifying flows that relate to IEPS
versus others that traverse a transit network. versus others that traverse a transit network.
At an abstract level, the forth objective pertains to the actions At an abstract level, the fourth objective pertains to the actions
taken when an IP telephony call, via a signaling protocol such as taken when an IP telephony call, via a signaling protocol such as
SIP, cannot be forwarded because the network is experiencing a form SIP, cannot be forwarded because the network is experiencing a form
of congestion. We state this in general terms because of two rea- of congestion. We state this in general terms because of two rea-
sons: a) there may exist applications other than SIP, like H.248, sons: a) there may exist applications other than SIP, like H.248,
used for call establishment, and b) congestion may come in several used for call establishment, and b) congestion may come in several
forms. For example, congestion may exist at the IP packet layer with forms. For example, congestion may exist at the IP packet layer with
respect to queues being filled to their configured limit. Congestion respect to queues being filled to their configured limit. Congestion
may also arise from resource allocation (i.e., QoS) attributed per may also arise from resource allocation (i.e., QoS) attributed per
call or aggregated sets of calls. In this latter case, while there call or aggregated sets of calls. In this latter case, while there
may exist resources to forward the packets, a signaling server may may exist resources to forward the packets, a signaling server may
skipping to change at page 9, line 44 skipping to change at page 9, line 52
expectation for ubiquitous support of IEPS across all administrative expectation for ubiquitous support of IEPS across all administrative
domains of the Internet. While it would be desirable to have ubiqui- domains of the Internet. While it would be desirable to have ubiqui-
tous support, we feel the reliance of such a requirement would doom tous support, we feel the reliance of such a requirement would doom
even the contemplation of supporting IEPS by the IETF and the even the contemplation of supporting IEPS by the IETF and the
expected entities (e.g., ISPs and vendors) involved in its deploy- expected entities (e.g., ISPs and vendors) involved in its deploy-
ment. ment.
We use the existing GETS service in the U.S. as an existing example We use the existing GETS service in the U.S. as an existing example
in which emergency related communications does not need to be ubiqui- in which emergency related communications does not need to be ubiqui-
tous. As mentioned previously, the measure and amount of support tous. As mentioned previously, the measure and amount of support
provided by the U.S. PSTN for GETS does bot exist for all U.S. IXCs provided by the U.S. PSTN for GETS does not exist for all U.S. IXCs
nor LECs. Given the fact that GETS still works within this context, nor LECs. Given the fact that GETS still works within this context,
it is our objective to follow this deployment model such that we can it is our objective to follow this deployment model such that we can
accomplish the first objective listed above -- a higher probability accomplish the first objective listed above -- a higher probability
of call completion than that of normal IP telephony call traffic. of call completion than that of normal IP telephony call traffic.
Our final objective is that only authorized users may use the ser- Our final objective is that only authorized users may use the ser-
vices outlined in this framework. GETS users are authenticated using vices outlined in this framework. GETS users are authenticated using
a PIN provided to the telecommunications carrier, which signals a PIN provided to the telecommunications carrier, which signals
approval back to the user's local exchange over SS7. In an IP net- authentication to subsequent networks via the HPC class mark. In an
work, the authentication center will need to securely signal back to IP network, the authentication center will need to securely signal
the IP ingress point that a given user is authorized to send IEPS back to the IP ingress point that a given user is authorized to send
related flows. Similarly, transit networks with IEPS SLAs must IEPS related flows. Similarly, transit networks with IEPS SLAs must
securely interchange authorized IEPS traffic. In both cases, IPSec securely interchange authorized IEPS traffic. In both cases, IPSec
authentication transforms may be used to protect this traffic. This authentication transforms may be used to protect this traffic. This
is entirely separate from end-to-end IPSec protection of user is entirely separate from end-to-end IPSec protection of user
traffic, which will be configured by users. IP-PSTN gateways must traffic, which will be configured by users. IP-PSTN gateways must
also be able to securely signal IEPS authorization for a given flow. also be able to securely signal IEPS authorization for a given flow.
As these gateways are likely to act as SIP servers, we further con- 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. sider the use of SIP's security functions to aid this objective.
3. Value Added Objective 3. Value Added Objective
skipping to change at page 10, line 39 skipping to change at page 10, line 46
This objective involves the ability to discover and use a different This objective involves the ability to discover and use a different
path to route IP telephony traffic around congestion points and thus path to route IP telephony traffic around congestion points and thus
avoid them. Ideally, the discovery process would be accomplished in avoid them. Ideally, the discovery process would be accomplished in
an expedient manner (possibly even a priori to the need of its an expedient manner (possibly even a priori to the need of its
existence). At this level, we make no requirements as to how the existence). At this level, we make no requirements as to how the
alternate path is accomplished, or even at which layer it is achieved alternate path is accomplished, or even at which layer it is achieved
-- e.g., the network versus the application layer. But this kind of -- e.g., the network versus the application layer. But this kind of
capability, at least in a minimal form, would help contribute to capability, at least in a minimal form, would help contribute to
increasing the probability of call completion of IEPS traffic by mak- increasing the probability of call completion of IEPS traffic by mak-
ing use of noncongested alternate paths. We use the term "minimal ing use of noncongested alternate paths. We use the term "minimal
form" to concede the fact that care must be taken in how the system form" to emphasize the fact that care must be taken in how the system
provides alternate paths so it does not significantly contribute to provides alternate paths so it does not significantly contribute to
the congestion that is to be avoided (e.g., via excess the congestion that is to be avoided (e.g., via excess
control/discovery messages). control/discovery messages).
At the time that this document was written, we can identify two At the time that this document was written, we can identify two
work-in-progress areas in the IETF that can be helpful in providing work-in-progress areas in the IETF that can be helpful in providing
alternate paths for call signaling. The first is [10], which is alternate paths for call signaling. The first is [10], which is
focused on network layer routing and describes enhancements to the focused on network layer routing and describes enhancements to the
LDP specification of MPLS to help achieve fault tolerance. This in LDP specification of MPLS to help achieve fault tolerance. This in
itself does not provide alternate path routing, but rather helps itself does not provide alternate path routing, but rather helps
skipping to change at page 13, line 16 skipping to change at page 13, line 23
1) Signaling 1) Signaling
2) Policy 2) Policy
3) Traffic Engineering 3) Traffic Engineering
4) Security 4) Security
4.1. Signaling 4.1. Signaling
Signaling is used to convey various information to either intermedi- Signaling is used to convey various information to either intermedi-
ate nodes or end nodes. It can be out-of-band of a data flow, and ate nodes or end nodes. It can be out-of-band of a data flow, and
thus in a separate flow of its own, such as SIP messages. It can be thus in a separate flow of its own, such as SIP messages. It can be
in-band and part of the datagram containing the voice data. This in-band and part of the state information in a datagram containing
latter example could be realized in the form of diff-serv code points the voice data. This latter example could be realized in the form of
in the IP packet, and/or in an extension to the RTP header denoting diff-serv code points in the IP packet.
an additional classification of the payload -- the latter predom-
inantly being used on an end-to-end basis.
In the following subsections, we discuss augmentations to three In the following subsections, we discuss potential augmentations to
specific types of signaling to help support the distinction of emer- different types of signaling and state information to help support
gency related communications in general, and IEPS specifically. We the distinction of emergency related communications in general, and
also discuss Media Gateway Control (MEGACO). IEPS specifically.
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
skipping to change at page 14, line 14 skipping to change at page 14, line 19
on the subject of policies below in section 4.2. on the subject of policies below in section 4.2.
Additional namespaces and value(s) would be registered with IANA. It Additional namespaces and value(s) would be registered with IANA. It
would be our intention to follow the approach taken in [15] and would be our intention to follow the approach taken in [15] and
register a new namespace attributed to IEPS. Unlike [15], we would register a new namespace attributed to IEPS. Unlike [15], we would
define a single value (e.g., "authorized-emergency") that would define a single value (e.g., "authorized-emergency") that would
correspond to the NS/EP code point of SS7. This will help facilitate correspond to the NS/EP code point of SS7. This will help facilitate
a seamless interaction between the PSTN and the an IP network acting a seamless interaction between the PSTN and the an IP network acting
as either an internal backbone or as a peering ISP. as either an internal backbone or as a peering ISP.
Author's Note #1: The work put forth by Polk in [34], which describes Note #1: The work put forth by Polk in [34], which describes an
an architecture for MLPP, is similar to the subject of IEPS in the architecture for MLPP, is similar to the subject of IEPS in the sense
sense that both aim at distinguishing certain VoIP flows from others. that both aim at distinguishing certain VoIP flows from others. How-
However, MLPP and IEPS are not the same efforts. One critical ever, MLPP and IEPS are not the same efforts. One critical differ-
difference is that MLPP involves the use of preemption, while the ence is that MLPP involves the use of preemption, while the default
default model for IEPS is simply an increase in the probability of model for IEPS is simply an increase in the probability of call com-
call completion. pletion.
Author's Note #2: The term "Priority" has been a subject of strong Note #2: The term "Priority" has been a subject of strong debate. In
debate. In this document, we reference the term based on the termi- this document, we reference the term based on the terminology inher-
nology inherited from other drafts and documents, such as can be ited from other drafts and documents, such as can be found in [15],
found in [15], and the Megaco RFC [23]. However, our focus is aimed and the Megaco RFC [23]. However, our focus is aimed at using the
at using the "priority" value as simply a label by which we distin- "priority" value as simply a label by which we distinguish one set of
guish one set of flows from another. flows from another.
4.1.2. Diff-Serv 4.1.2. Diff-Serv
In accordance with [16], the differentiated services code point In accordance with [16], the differentiated services code point
(DSCP) field is divided into three sets of values. The first set is (DSCP) field is divided into three sets of values. The first set is
assigned by IANA. Within this set, there are currently, three types assigned by IANA. Within this set, there are currently, three types
of Per Hop Behaviors that have been specified: Default (correlating of Per Hop Behaviors that have been specified: Default (correlating
to best effort forwarding), Assured Forwarding, and Expedited For- to best effort forwarding), Assured Forwarding, and Expedited For-
warding. The second set of DSCP values are set aside for local or warding. The second set of DSCP values are set aside for local or
experimental use. The third set of DSCP values are also set aside experimental use. The third set of DSCP values are also set aside
for local or experimental use, but may later be reassigned to IANA in for local or experimental use, but may later be reassigned to IANA in
case the first set has been completely assigned. case the first set has been completely assigned.
One candidate recomendation involves the specification of a new type One candidate recomendation involves the specification of a new type
of Per-Hop Behavior (PHB) we term Emergency Related Forwarding (ERF). of Per-Hop Behavior (PHB). This would provide a specific means of
This would provide a specific means of distinguishing emergency distinguishing emergency related traffic (signaling and user data)
related traffic (signaling and user data) from other traffic. The from other traffic. The existence of this PHB then provides a base-
existence of this PHB then provides a baseline by which specific code line by which specific code points may be defined related to various
points may be defined related to various emergency related traffic: emergency related traffic: authorized emergency sessions (e.g.,
authorized emergency sessions (e.g., IEPS), general public emergency IEPS), general public emergency calls (e.g., "911"), MLPP. Aggre-
calls (e.g., "911"), MLPP. Aggregates would still exist with respect gates would still exist with respect to the bundling of applications
to the bundling of applications per code point. Further, one would per code point. Further, one would associate a forwarding paradigm
associate a forwarding paradigm aimed at a low loss rate reflective aimed at a low loss rate reflective of the code point selected. The
of the code point selected. Hence, SIP or H.323 messages marked with new PHB could be in the form of a one or more code points that dupli-
"authorized-emergency" or "emergency" may be assigned a code point cate EF-type traffic characteristics. Policies would determine IF a
reflecting a lower loss rate than other type of traffic (even the measure of importance exists per EF-type code-point.
emergency-related data flow itself). The jitter associated with
application layer signaling of IP telephony would be inversely impor-
tant with respect to loss rate, and thus would be reflective of the
code points defined for the proposed PHB.
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
congestion of EF queues at internal/core merge points steming from congestion of EF queues at internal/core merge points stemming from
flows originating from different ingress nodes of the diff-serv flows originating from different ingress nodes of the diff-serv
domain. However, traffic engineering may not be able to compensate domain. However, traffic engineering may not be able to compensate
for congestion of EF-type traffic at the domain's core routers. for congestion of EF-type traffic at the domain's core routers.
Hence, a new PHB that has more than one code point to identify EF- Hence, a new PHB that has more than one code point to identify EF-
type traffic may address congestion by associating a drop precedence type traffic may address congestion by associating a drop precedence
for certain types of EF-type datagrams. Note that local policy and for certain types of EF-type datagrams. Note that local policy and
SLAs would define which EF-type of traffic, if any, would be associ- SLAs would define which EF-type of traffic, if any, would be associ-
ated with a specific drop precedence. ated with a specific drop precedence.
Another candidate recomendation would be to define a new or fifth Another candidate recomendation would be to define a new or fifth
class for the existing AF PHB. Unlike the other currently defined class for the existing AF PHB. Unlike the other currently defined
classes, this new one would be based on five levels of drop pre- classes, this new one would be based on five levels of drop pre-
cedence. This increase in the number of levels would conveniently cedence. This increase in the number of levels would conveniently
correlate to the worst case scenario posed by MLPP, which has five correlate to the the levels of MLPP, which has five types of priori-
types of priorities. In addition, it would provide a higher level of ties. The five levels would also correlate to a recent effort in the
variance that could be used to supercede the existing 3 levels used Study Group 11 of the ITU to define 5 levels for Emergency Telecom-
in the other classes. Hence, if other non-emergency aggregate munications Service (ETS). Beyond these other standardization
traffic where assigned to the class, the highest drop precedence they efforts, the 5 levels would provide a higher level of variance that
are assigned to is (3) -- corresponding to the other four currently could be used to supercede the existing 3 levels used in the other
classes. Hence, if other non-emergency aggregate traffic were
assigned to the new class, the highest drop precedence they are
assigned to is (3) -- corresponding to the other four currently
defined classes. Emergency traffic would be set to (4) or (5), defined classes. Emergency traffic would be set to (4) or (5),
depending on the SLA tht has been defined. depending on the SLA tht has been defined.
It is important to note that as of the time that this document was It is important to note that as of the time that this document was
written, the IETF is taking a conservative approach in specifying new written, the IETF is taking a conservative approach in specifying new
PHBs. This is because the number of code points that can be defined PHBs. This is because the number of code points that can be defined
is relatively small, and thus understandably considered a scarce is relatively small, and thus understandably considered a scarce
resource. Therefore, the possibility of a new PHB being defined for resource. Therefore, the possibility of a new PHB being defined for
emergency related traffic is at best a long term project that may or emergency related traffic is at best a long term project that may or
may not be accepted by the IETF. In the near term, we would ini- may not be accepted by the IETF. In the near term, we would ini-
skipping to change at page 16, line 39 skipping to change at page 16, line 43
effort. effort.
In 4.1.2, we discussed one means of marking a data packet for emer- In 4.1.2, we discussed one means of marking a data packet for emer-
gencies under the context of the diff-serv architecture. However, we gencies under the context of the diff-serv architecture. However, we
also pointed out that diff-serv markings for specific PHBs are not also pointed out that diff-serv markings for specific PHBs are not
globally unique, and may be arbitrarily removed or even changed by globally unique, and may be arbitrarily removed or even changed by
intermediary nodes or domains. Hence, with respect to emergency intermediary nodes or domains. Hence, with respect to emergency
related data packets, we are still missing an in-band marking in a related data packets, we are still missing an in-band marking in a
data packet that stays constant on an end-to-end basis. data packet that stays constant on an end-to-end basis.
We have three choices in defining a persistent marking of data pack- There are have three choices in defining a persistent marking of data
ets and thus avoid the transitory marking of diff-serv code points. packets and thus avoid the transitory marking of diff-serv code
We can propose a new PHB dedicated for emergency type traffic as dis- points. We can propose a new PHB dedicated for emergency type
cussed in 4.1.2. We can propose a specification of a new shim layer traffic as discussed in 4.1.2. We can propose a specification of a
protocol at some location above IP. Or, we can add a new specifica- new shim layer protocol at some location above IP. Or, we can add a
tion to an existing upper layer protocol. The first two cases are new specification to an existing application layer protocol. The
probably the "cleanest" architecturally, but they are long term first two cases are probably the "cleanest" architecturally, but they
efforts that will take time to support in terms of design and imple- are long term efforts that may not come to pass because of a limited
mentation. It also may be argued that yet another shim layer will amount of diff-serv code points and the contention that yet another
make the IP stack too large. The third case, placing a marking in an shim layer will make the IP stack too large. The third case, placing
application layer packet, has the potential to be more appealing a marking in an application layer packet, also has drawbacks; the key
depending on where the augmentation is targeted. weakness being the specification of a marking on a per-application
basis.
An approach in realizing this third case involves an augmentation to Discussions have been held in the Audio/Visual Transport (AVT) work-
RTP so that it can carry a marking that distinguishes emergency- ing group of augmenting RTP so that it can carry a marking that dis-
related traffic from that which is not. Specifically, one would tinguishes emergency-related traffic from that which is not. Specif-
define a new extention that contains a "classifier" field indicating ically, one would define a new extention that contains a "classifier"
the condition associated with the packet (e.g., authorized-emergency, field indicating the condition associated with the packet (e.g.,
emergency, normal) [29]. authorized-emergency, emergency, normal) [29]. The rationale behind
this idea was that focusing on RTP would allow one to rely on a point
of aggregation that would apply to all payloads that it encapsulates.
However, the AVT group has expressed a rough consensus that placing
additional classifier state in the RTP header to denote the impor-
tance of one flow over another is not an approach that wish to
advance. Objections ranging from relying on SIP to convey importance
of a flow, as well as the possibility of adversely affecting header
compression, were expressed. There was also the general feeling that
the extension header for RTP should not be used for RTP packet of a
flow.
An issue in defining a new extension to RTP is that its presence may Author's note: There was some debate as to whether to keep the above
adversely affect header compression for those implementations that subsection concerning RTP in this document. We have decided to
are not expecting added optional octets in RTP packets. In addition, retain it because it is felt that information concerning directions
the issue of security and authentication of such a marking remains an that should NOT be taken to support IEPS is important to the commun-
important issue and is subject to the constraints discussed below in ity at large.
section 4.4, and in more detail in [27].
4.1.4. MEGACO/H.248 4.1.4. MEGACO/H.248
The Media Gateway Control protocol (MEGACO) [23] defines the interac- The Media Gateway Control protocol (MEGACO) [23] defines the interac-
tion between a media gateway and a media gateway controller. [23] is tion between a media gateway and a media gateway controller. [23] is
viewed as common text with ITU-T Recommendation H.248 and is a result viewed as common text with ITU-T Recommendation H.248 and is a result
of applying the changes of RFC 2886 (Megaco Errata) to the text of of applying the changes of RFC 2886 (Megaco Errata) to the text of
RFC 2885 (Megaco Protocol version 0.8). RFC 2885 (Megaco Protocol version 0.8).
In [23], the protocol specifies a Priority and Emergency field for a In [23], the protocol specifies a Priority and Emergency field for a
skipping to change at page 24, line 32 skipping to change at page 24, line 47
32 Hardman, V., et al, "Reliable Audio for Use over the Internet", 32 Hardman, V., et al, "Reliable Audio for Use over the Internet",
Proceedings, INET'95, Aug, 1995. Proceedings, INET'95, Aug, 1995.
33 Awduche, D, et al, "Requirements for Traffic Engineering Over 33 Awduche, D, et al, "Requirements for Traffic Engineering Over
MPLS", Informational, RFC 2702, September, 1999. MPLS", Informational, RFC 2702, September, 1999.
34 Polk, J., "An Architecture for Multi-Level Precedence and 34 Polk, J., "An Architecture for Multi-Level Precedence and
Preemption over IP", Internet Draft, Work In Progress, Preemption over IP", Internet Draft, Work In Progress,
November, 2001. November, 2001.
8. Acknowledgments 35 "Service Class Designations for H.323 Calls", ITU Draft
Recommendation H.GEF.4, September, 2001
8. Appendix A: Government Telephone Preference Scheme (GTPS)
This framework document uses U.S. GETS as a target model for defining
a framework for supporting authorized emergency related communication
within the context of IP telephony. We take this position because of
the various areas that must be considered; from the application layer
to the (inter)network layer, in addition to policy, security (author-
ized access), and traffic engineering.
The U.K. has a different type of authorized use of telephony services
referred to as the Government Telephone Preference Scheme (GTPS).
This service was introduced in the 1950's at a time when loss of
power to the PSTN due to war or natural disaster was of prime con-
cern. If a loss of power did occur, it was felt that the critical
issue was to take action to limit phone usage by the general public
so that power would be conserved for use by critical personnel
involved in an emergency.
The design and implementation of GTPS focused on the ability of the
U.K. PSTN to withdraw outgoing telephone service from the majority
of the general public. Inbound calls can still be received, but the
net effect of the action is that power for the phone line service is
conserved. It can probably be argued that power loss is not as
important an issue today as it was back in the 50's. And in fact
Oftel, the U.K. regulatory authority, is planning an evolutionary
change to GTPS so that it reflects current needs and requirements for
supporting emergency communications through the U.K. PSTN -- such as
congestion, and the ability to provide roaming authorized access like
that of GETS.
At present, all local exchange access points (ie, phones) are divided
into three categories:
1: Time of War: people that are involved in operations and planning
of a war or war conditions
2: Natural Disaster: individuals that are involved in recovery and
operations associated with natural disasters.
3: General Public: people that are not associated with categories
1 and 2, which is essentially over 99% of the population.
Unlike the roaming ability of GETS users, GTPS associates preference
with an originating phone. This simplifies the process of determin-
ing who is allowed outbound phone service, but it is also quite res-
trictive in its usage. Hence, individuals that want preferential
service must use the phone that has been designated as Category 1 or
2. Note: for the general public, pay phones have been designated as
Category 2 so that 999 (emergency calls to fire or police) can be
made.
In 1984, an updated version of GTPS was made available following the
deregulation of the U.K. phone system. In this new scheme, local
exchanges retained the three category system while inter-exchange
calls use call-gaping. Priority marks, via C7/NUP, would bypass the
call-gaping. The authority to activate GTPS was also extended to the
46 Constables (i.e., local police chiefs) of the U.K. -- each being
responsible for their own jurisdiction.
8.1. GTPS and the Framework Document
The design of the current GTPS, with its designation of preference
based on physical static devices, precludes the need for several
aspects presented in this document. However, one component that can
have a direct correlation is the labeling capability of the proposed
Resource Priority extension to SIP. In the case of GTPS, one simply
needs to define a new NameSpace that will define values for each of
its three Categories of users. These new labels will then allow a
more transparant interoperation between IP telephony using SIP and
the U.K. PSTN that supports GTPS.
Restricting outbound call establishment within the context of IP
telephony and SIP servers is a policy issue. Service Level Agree-
ments, presumably under the guidance or direction of local laws and
regulations would determine the characteristics of the policy.
9. Appendix B: Related Standards Work
The process of defining various labels to distinguish calls has been,
and continues to be, pursued in other standards groups. As mentioned
in section 1.1.1, the ANSI T1S1 group has previously defined a label
SS7 ISUP Initial Address Message. This single label or value is
referred to as the National Security and Emergency Preparedness
(NS/EP) indicator and is part of the T1.631 standard. The following
subsections presents a snap shot of parallel on-going efforts in
various standards groups.
It is important to note that the recent activity in other groups have
gravitated to defining 5 labels or levels of priority. The impact of
this approach is minimal in relation to this IEPS framework document
because it simply generates a requirement to define and register with
IANA a new NameSpace in the Resource-Priority header of SIP.
9.1. Study Group 16 (ITU)
Study Group 16 (SG16) of the ITU is responsible for studies relating
to multimedia service definition and multimedia systems, including
protocols and signal processing.
A draft contribution [35] has been introduced into this group that
would add a Priority Class parameter to the call establishment mes-
sages of H.323. This class is further divided into two parts; one
for Priority Value and the other is a Priority Extension for indicat-
ing subclasses. It is this former part that roughly corresponds to
the labels transported via the Resource Priority field for SIP [15].
The draft recommendation advocates defining PriorityClass information
that would be carried in the GenericData parameter in the H323-UU-PDU
or RAS messages. The GenericData parameter contains Priori-
tyClassGenericData. The PriorityClassInfo of the PriorityClassGener-
icData contains the Priority and Priority Extension fields.
At present, 5 levels have been defined for the Priority Value part of
the Priority Class parameter: Low, Normal, High, Emergency-Public,
Emergency-Authorized. An additional 8-bit priority extension has been
defined to provide for subclasses of service at each priority.
The suggested ASN.1 definition of the service class is the following:
ServiceClassInfo ::= SEQUENCE
{
priority CHOICE
{
emergencyAuthorized NULL,
emergencyPublic NULL,
high NULL,
normal NULL,
low NULL
}
priorityExtension INTEGER (0..255) OPTIONAL;
requiredClass NULL OPTIONAL
tokens SEQUENCE OF ClearToken OPTIONAL
cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL
}
The advantage in using the GenericData parameter is that an existing
parameter is used, as opposed to defining a new parameter and causing
subsequent changes in existing H.323/H.225 documents.
9.2. Study Group 11 (ITU)
To Be Done...
9.3. T1S1 (ANSI)
To Be Done...
10. Acknowledgments
The authors would like to acknowledge the helpful comments, opinions, The authors would like to acknowledge the helpful comments, opinions,
and clarifications of Stu Goldman and James Polk, as well as those and clarifications of Stu Goldman, James Polk, Dennis Berg, as well
comments received from the IEPS mailing list. as those comments received from the IEPS and IEPREP mailing lists.
Additional thanks to Peter Walker of Oftel for private discussions on
the operation of GTPS, and Gary Thom on clarifications of the SG16
draft contribution.
9. 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
Table of Contents Table of Contents
1. Introduction ................................................... 2 1. Introduction ................................................... 2
1.1 Emergency Related Data ....................................... 3 1.1 Emergency Related Data ....................................... 3
1.1.1 Government Emergency Telecommunications Service (GETS) ..... 3 1.1.1 Government Emergency Telecommunications Service (GETS) ..... 3
1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 5 1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 5
1.2 Scope of this Document ....................................... 5 1.2 Scope of this Document ....................................... 5
2. Objective ..................................................... 7 2. Objective ..................................................... 7
3. Value Added Objective ......................................... 10 3. Value Added Objective ......................................... 10
3.1 Alternate Path Routing ....................................... 10 3.1 Alternate Path Routing ....................................... 10
3.2 End-to-End Fault Tolerance ................................... 11 3.2 End-to-End Fault Tolerance ................................... 12
4. Functional Requirements ....................................... 12 4. Functional Requirements ....................................... 12
4.1 Signaling .................................................... 13 4.1 Signaling & State Information ................................ 13
4.1.1 SIP ........................................................ 13 4.1.1 SIP ........................................................ 13
4.1.2 Diff-Serv .................................................. 14 4.1.2 Diff-Serv .................................................. 14
4.1.3 RTP ........................................................ 16 4.1.3 RTP ........................................................ 16
4.1.4 MEGACO/H.248 ............................................... 17 4.1.4 MEGACO/H.248 ............................................... 17
4.2 Policy ....................................................... 17 4.2 Policy ....................................................... 18
4.3 Traffic Engineering .......................................... 18 4.3 Traffic Engineering .......................................... 18
4.4 Security ..................................................... 19 4.4 Security ..................................................... 19
5. Key Scenarios ................................................. 19 5. Key Scenarios ................................................. 20
6. Security Considerations ....................................... 22 6. Security Considerations ....................................... 22
7. References .................................................... 22 7. References .................................................... 22
8. Acknowledgments ............................................... 24 8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 25
9. Author's Addresses ............................................ 24 8.1 GTPS and the Framework Document .............................. 26
9. Appendix B: Related Standards Work ............................ 26
9.1 Study Group 16 (ITU) ......................................... 27
9.2 Study Group 11 (ITU) ......................................... 28
9.3 T1S1 (ANSI) .................................................. 28
10. Acknowledgments .............................................. 28
11. Author's Addresses ........................................... 28
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
 End of changes. 

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