draft-ietf-ieprep-framework-09.txt   draft-ietf-ieprep-framework-10.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
February 5, 2004 Ian Brown Oct 19, 2004 Ian Brown
UCL UCL
Cory Beard Cory Beard
UMKC UMKC
Framework for Supporting ETS in IP Telephony Framework for Supporting Emergency Telecommunications Service
<draft-ietf-ieprep-framework-09.txt> (ETS) in IP Telephony
<draft-ietf-ieprep-framework-10.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 subject to all provisions
all provisions of Section 10 of RFC2026 [1]. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
groups may also distribute working documents as Internet-Drafts. other 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
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft http://www.ietf.org/ietf/1id-abstracts.txt.
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
For potential updates to the above required-text see: The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/ietf/1id-guidelines.txt http://www.ietf.org/shadow.html.
Abstract Abstract
This document presents a framework for supporting authorized This document presents a framework for supporting authorized
emergency related communication within the context of IP telephony. emergency related communication within the context of IP telephony.
We present a series of objectives that reflect a general view of how We present a series of objectives that reflect a general view of how
authorized emergency service, in line with the Emergency authorized emergency service, in line with the Emergency
Telecommunications Service (ETS), should be realized within today's Telecommunications Service (ETS), should be realized within today's
IP architecture and service models. From these objectives, we IP architecture and service models. From these objectives, we
present a corresponding set of protocols and capabilities, which present a corresponding set of protocols and capabilities, which
skipping to change at page 2, line 45 skipping to change at page 2, line 49
seems unlikely that the original vision of end-to-end int-serv seems unlikely that the original vision of end-to-end int-serv
between hosts in source and destination stub domains will become a between hosts in source and destination stub domains will become a
reality in the near future (the mid- to far-term is a subject for reality in the near future (the mid- to far-term is a subject for
others to contemplate). others to contemplate).
In 1998, the IETF produced [8], which presented an architecture for In 1998, the IETF produced [8], which presented an architecture for
Differentiated Services (diff-serv). This effort focused on a more Differentiated Services (diff-serv). This effort focused on a more
aggregated perspective and classification of packets than that of aggregated perspective and classification of packets than that of
[2]. This is accomplished with the recent specification of the [2]. This is accomplished with the recent specification of the
diff-serv field in the IP header (in the case of IPv4, it replaced diff-serv field in the IP header (in the case of IPv4, it replaced
the old ToS field). This new field is used for code points esta- the old ToS field). This new field is used for code points
blished by IANA, or set aside as experimental. It can be expected established by IANA, or set aside as experimental. It can be
that sets of microflows, a granular identification of a set of pack- expected that sets of microflows, a granular identification of a set
ets, will correspond to a given code point, thereby achieving an of packets, will correspond to a given code point, thereby achieving
aggregated treatment of data. an aggregated treatment of data.
One constant in the introduction of new service models has been the One constant in the introduction of new service models has been the
designation of Best Effort as the default service model. If traffic designation of Best Effort as the default service model. If traffic
is not, or cannot be, associated as diff-serv or int-serv, then it is is not, or cannot be, associated as diff-serv or int-serv, then it is
treated as Best Effort and uses what resources are made available to treated as Best Effort and uses what resources are made available to
it. it.
Beyond the introduction of new services, the continued pace of addi- Beyond the introduction of new services, the continued pace of addi-
tional traffic load experienced by ISPs over the years has continued tional traffic load experienced by ISPs over the years has continued
to place a high importance for intra-domain traffic engineering. The to place a high importance for intra-domain traffic engineering. The
skipping to change at page 5, line 19 skipping to change at page 5, line 26
makes an argument that there is a maximum packet loss and delay for makes an argument that there is a maximum packet loss and delay for
VoIP traffic, and both are interdependent. For delays of ~200ms, a VoIP traffic, and both are interdependent. For delays of ~200ms, a
corresponding drop rate of 5% is deemed acceptable. When delay is corresponding drop rate of 5% is deemed acceptable. When delay is
lower, a 15-20% drop rate can be experienced and still considered lower, a 15-20% drop rate can be experienced and still considered
acceptable. [32] discusses the same topic and makes an arguement acceptable. [32] discusses the same topic and makes an arguement
that packet size plays a significant role in what users tolerate as that packet size plays a significant role in what users tolerate as
"intelligible" VoIP. The larger the packet, correlating to longer "intelligible" VoIP. The larger the packet, correlating to longer
sampling rate, the lower the acceptable rate of loss. Note that sampling rate, the lower the acceptable rate of loss. Note that
[31,32] provide only two of several perspectives in examining VoIP. [31,32] provide only two of several perspectives in examining VoIP.
A more indepth discussion on this topic is outside the scope of this A more indepth discussion on this topic is outside the scope of this
document. document, though it should be noted that the choice of codec can sig-
nificantly alter the above results.
Regardless of a single and definitive characteristic for stressed Regardless of a single and definitive characteristic for stressed
conditions, it would seem that interactive voice has a lower thres- conditions, it would seem that interactive voice has a lower thres-
hold of some combinations of loss/delay/jitter than elastic applica- hold of some combinations of loss/delay/jitter than elastic applica-
tions such as email or web browsers. This places a higher burden on tions such as email or web browsers. This places a higher burden on
the problem space of supporting VoIP over the Internet. This problem the problem space of supporting VoIP over the Internet. This problem
is further compounded when toll-quality service is expected because is further compounded when toll-quality service is expected because
it assumes a default service model that is better than best effort. it assumes a default service model that is better than best effort.
This in turn can increase the probability that a form of call- This in turn can increase the probability that a form of call-
blocking can occur with VoIP or IP telephony traffic. blocking can occur with VoIP or IP telephony traffic.
skipping to change at page 6, line 41 skipping to change at page 6, line 50
3. Considerations 3. Considerations
When producing a solution, or examining existing protocols and When producing a solution, or examining existing protocols and
mechanisms, there are some things that should be considered. One is mechanisms, there are some things that should be considered. One is
that inter-domain ETS communications should not rely on ubiquitous or that inter-domain ETS communications should not rely on ubiquitous or
even wide-spread support along the path between the end points. even wide-spread support along the path between the end points.
Potentially, at the network layer there may exist islands of support Potentially, at the network layer there may exist islands of support
realized in the form of overlay networks. There may also be cases realized in the form of overlay networks. There may also be cases
where solutions may be constrained on an end-to-end basis (i.e., at where solutions may be constrained on an end-to-end basis (i.e., at
the transport or application layer). It is this diversity and possi- the transport or application layer). It is this diversity and
bly partial support that need to be taken into account by those possibly partial support that need to be taken into account by those
designing and deploying ETS related solutions. designing and deploying ETS related solutions.
Another aspect to consider is that there are existing architectures Another aspect to consider is that there are existing architectures
and protocols from other standards bodies that support emergency and protocols from other standards bodies that support emergency
related communications. The effort in interoperating with these sys- related communications. The effort in interoperating with these sys-
tems, presumably through gateways or similar type nodes with IETF tems, presumably through gateways or similar type nodes with IETF
protocols, would foster a need to distinguish ETS flows from other protocols, would foster a need to distinguish ETS flows from other
flows. One reason would be the scenario of triggering ETS service flows. One reason would be the scenario of triggering ETS service
from an IP network. from an IP network.
skipping to change at page 7, line 41 skipping to change at page 7, line 49
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.
In the following subsections, we discuss the current state of some In the following subsections, we discuss the current state of some
protocols and their use in providing support for ETS. We also dis- protocols and their use in providing support for ETS. We also
cuss potential augmentations to different types of signaling and discuss potential augmentations to different types of signaling and
state information to help support the distinction of emergency state information to help support the distinction of emergency
related communications in general. related communications in general.
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",
skipping to change at page 8, line 34 skipping to change at page 8, line 41
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 approach discussed on the IEPREP mailing list is the specifica- One approach discussed on the IEPREP mailing list is the specifica-
tion of a new Per-Hop Behaviour (PHB) for emergency related flows. tion of a new Per-Hop Behaviour (PHB) for emergency related flows.
The rationale behind this idea is that it would provide a baseline by The rationale behind this idea is that it would provide a baseline by
which specific code points may be defined for various emergency which specific code points may be defined for various emergency
related traffic: authorized emergency sessions (e.g., ETS), general related traffic: authorized emergency sessions (e.g., ETS), general
public emergency calls (e.g., "911"), MLPP, etc. However, in order public emergency calls (e.g., "911"), Multi-Level Precedence and
to define a new set of code points, a forwarding characteristic must Preemption (MLPP), etc. However, in order to define a new set of
also be defined. In other words, one cannot simply identify a set of code points, a forwarding characteristic must also be defined. In
bits without defining their intended meaning (e.g.,the drop pre- other words, one cannot simply identify a set of bits without defin-
cedence approach of Assured Forwarding). The one caveat to this ing their intended meaning (e.g.,the drop precedence approach of
statement are the set of DSCP bits set aside for experimental pur- Assured Forwarding). The one caveat to this statement are the set of
poses. But as the name implies, experimental is for internal examina- DSCP bits set aside for experimental purposes. But as the name
tion and use and not for standardization. implies, experimental is for internal examination and use and not for
standardization.
Comments Comments
-------- --------
It is important to note that as of the time that this document was It is important to note that as of the time that this document was
written, the IETF has been taking a conservative approach in specify- written, the IETF has been taking a conservative approach in specify-
ing new PHBs. This is because the number of code points that can be ing new PHBs. This is because the number of code points that can be
defined is relatively small and understandably considered a scarce defined is relatively small and 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. may not be accepted by the IETF.
In the near term, we would initially suggest using the Assured For- In the near term, we would initially suggest using the Assured For-
warding (AF) PHB [20] for distinguishing emergency traffic from other warding (AF) PHB [20] for distinguishing emergency traffic from other
types of flows. At a minimum, AF could be used for the different SIP types of flows. At a minimum, AF could be used for the different SIP
call signaling messages. If EF was also supported by the domain, call signaling messages. If the Expedited Forwarding (EF) PHB [44]
then it would be used for IP telephony data packets. Otherwise, was also supported by the domain, then it would be used for IP
another AF class would be used for those data flows. telephony data packets. Otherwise, another AF class would be used
for those data flows.
4.1.3. Variations Related to Diff-Serv and Queuing 4.1.3. Variations Related to Diff-Serv and Queuing
Scheduling mechanisms like Weighted Fair Queueing and Class Based Scheduling mechanisms like Weighted Fair Queueing and Class Based
Queueing are used to designate a percentage of the output link Queueing are used to designate a percentage of the output link
bandwidth that would be used for each class if all queues were back- bandwidth that would be used for each class if all queues were back-
logged. Its purpose, therefore, it to manage the rates and delays logged. Its purpose, therefore, it to manage the rates and delays
experienced by each class. But emergency traffic may not necessarily experienced by each class. But emergency traffic may not necessarily
require QoS any better or different than non-emergency traffic. It require QoS any better or different than non-emergency traffic. It
may just need higher probability of being forwarded to the next hop, may just need higher probability of being forwarded to the next hop,
skipping to change at page 12, line 41 skipping to change at page 12, line 50
mechanism of choice by an ISP. mechanism of choice by an ISP.
As a counter example of using a specific protocol to achieve traffic As a counter example of using a specific protocol to achieve traffic
engineering, [41] presents an example by one ISP relying on a high engineering, [41] presents an example by one ISP relying on a high
amount of overprovisioning within its core to satisfy potentially amount of overprovisioning within its core to satisfy potentially
dramatic spikes or bursts of traffic load. In this approach, any dramatic spikes or bursts of traffic load. In this approach, any
configuring of queues for specific customers (neighbors) to support configuring of queues for specific customers (neighbors) to support
target QoS is done on the egress edge of the transit network. target QoS is done on the egress edge of the transit network.
Note: As a point of reference, existing SLAs established by the NCS Note: As a point of reference, existing SLAs established by the NCS
for GETS service tend to focus on a loosely defined maximum alloca- for GETS service tend to focus on a loosely defined maximum
tion of (e.g., 1% to 10%) of calls allowed to be established through allocation of (e.g., 1% to 10%) of calls allowed to be established
a given LEC using HPC. It is expected, and encouraged, that ETS through a given LEC using HPC. It is expected, and encouraged, that
related SLAs of ISPs will have a limit with respect to the amount of ETS related SLAs of ISPs will have a limit with respect to the amount
traffic distinguished as being emergency related, and initiated by an of traffic distinguished as being emergency related, and initiated by
authorized user. an authorized user.
4.4. Security 4.4. Security
This section provides a brief overview of the security issues raised This section provides a brief overview of the security issues raised
by ETS support. by ETS support.
4.4.1. Denial of Service 4.4.1. Denial of Service
Any network mechanism that enables a higher level of priority for a Any network mechanism that enables a higher level of priority for a
specific set of flows could be abused to enhance the effectiveness of specific set of flows could be abused to enhance the effectiveness of
skipping to change at page 13, line 40 skipping to change at page 13, line 45
ities for DoS attacks. ities for DoS attacks.
As mentioned in section 4.3, SLAs for ETS facilities often contain As mentioned in section 4.3, SLAs for ETS facilities often contain
maximum limits on the level of ETS traffic that should be prioritised maximum limits on the level of ETS traffic that should be prioritised
in a particular network (say 1% of the maximum network capacity). in a particular network (say 1% of the maximum network capacity).
This should also be the case in IP networks to again reduce the level This should also be the case in IP networks to again reduce the level
of resources that a denial of service attack can consume. of resources that a denial of service attack can consume.
As of this writing, a typical inter-provider IP link uses 1 Gbps Eth- As of this writing, a typical inter-provider IP link uses 1 Gbps Eth-
ernet, OC-48 SONET/SDH, or some similar or faster technology. Also ernet, OC-48 SONET/SDH, or some similar or faster technology. Also
as of this writing, it is not practical to deploy per-packet crypto- as of this writing, it is not practical to deploy per-IP packet cryp-
graphic authentication on such inter-provider links, although such tographic authentication on such inter-provider links, although such
authentication might well be needed to provide assurance of IP-layer authentication might well be needed to provide assurance of IP-layer
label integrity in the inter-provider scenario. label integrity in the inter-provider scenario.
While Moore's Law will speed up cryptographic authentication, it is While Moore's Law will speed up cryptographic authentication, it is
unclear whether that is helpful because the speed of the typical unclear whether that is helpful because the speed of the typical
inter-domain link is also increasing rapidly. inter-domain link is also increasing rapidly.
4.4.2. User authorization 4.4.2. User authorization
To prevent theft of service and reduce the opportunities for denial To prevent theft of service and reduce the opportunities for denial
skipping to change at page 14, line 43 skipping to change at page 14, line 47
its user authentication procedures. These procedures may occur at the its user authentication procedures. These procedures may occur at the
link, network or higher layers, but are at the discretion of a single link, network or higher layers, but are at the discretion of a single
domain network. That network must decide how often it should update domain network. That network must decide how often it should update
its list of authorized ETS users based on the bounds it is prepared its list of authorized ETS users based on the bounds it is prepared
to accept on traffic from recently-revoked users. to accept on traffic from recently-revoked users.
If ETS support moves from intra-domain PSTN and IP networks to If ETS support moves from intra-domain PSTN and IP networks to
inter-domain end-to-end IP, verifying the authorization of a given inter-domain end-to-end IP, verifying the authorization of a given
flow becomes more complex. The user's access network must verify a flow becomes more complex. The user's access network must verify a
user's ETS authorization if network-layer priority is to be provided user's ETS authorization if network-layer priority is to be provided
at that point. Domains whose peering agreements include ETS support at that point.
must have the means to securely signal to each other a given flow's
ETS status. They may use physical link security combined with traffic Administrative domains that agree to exchange ETS traffic must have
the means to securely signal to each other a given flow's ETS status.
They may use physical link security combined with traffic
conditioning measures to limit the amount of ETS traffic that may conditioning measures to limit the amount of ETS traffic that may
pass between the two domains. The peering agreement must require the pass between the two domains. This agreement must require the ori-
originating network to take responsibility for ensuring that only ginating network to take responsibility for ensuring that only
authorized traffic is marked with ETS priority, but the recipient authorized traffic is marked with ETS priority, but the recipient
network cannot rely on this happening with 100% reliability. Both network cannot rely on this happening with 100% reliability. Both
domains should perform conditioning to prevent the propagation of domains should perform conditioning to prevent the propagation of
theft and denial of service attacks. theft and denial of service attacks. Note that administrative
domains that agree to exchange ETS traffic must deploy facilities
that perform these conditioning and security services at every point
at which they interconnect with one another.
Processes using application-layer protocols such as SIP should use Processes using application-layer protocols such as SIP should use
the security functionality in those protocols to verify the authori- the security functionality in those protocols to verify the authori-
zation of a session before allowing it to use ETS mechanisms. zation of a session before allowing it to use ETS mechanisms.
4.4.3. Confidentiality and integrity 4.4.3. Confidentiality and integrity
When ETS communications are being used to respond to a deliberate When ETS communications are being used to respond to a deliberate
attack, it is important that they cannot be altered or intercepted to attack, it is important that they cannot be altered or intercepted to
worsen the situation -- for example, by changing the orders to first worsen the situation -- for example, by changing the orders to first
skipping to change at page 15, line 41 skipping to change at page 15, line 51
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 ETS call completion by making use of increasing the probability of ETS call completion by making use of
noncongested alternate paths. We use the term "minimal form" to noncongested alternate paths. We use the term "minimal form" to
emphasize the fact that care must be taken in how the system provides emphasize the fact that care must be taken in how the system provides
alternate paths so it does not significantly contribute to the alternate paths so it does not significantly contribute to the
congestion that is to be avoided (e.g., via excess control/discovery congestion that is to be avoided (e.g., via excess control/discovery
messages). messages).
Routing protocols at the IP network layer, such as BGP and OSPF, con- Routing protocols at the IP network layer, such as BGP and OSPF,
tain mechanisms for determining link failure between routing peers. contain mechanisms for determining link failure between routing
The discovery of this failure automatically causes information to be peers. The discovery of this failure automatically causes informa-
propagated to other routers. The form of this information, the tion to be propagated to other routers. The form of this informa-
extent of its propagation, and the convergence time in determining tion, the extent of its propagation, and the convergence time in
new routes is dependent on the routing protocol in use. In the exam- determining new routes is dependent on the routing protocol in use.
ple of OSPF's Equal Cost Multiple Path (ECMP), the impact of link In the example of OSPF's Equal Cost Multiple Path (ECMP), the impact
failure is minimized because of pre-existing alternate paths to a of link failure is minimized because of pre-existing alternate paths
destination. to a destination.
At the time that this document was written, we can identify two addi- At the time that this document was written, we can identify two addi-
tional areas in the IETF that can be helpful in providing alternate tional areas in the IETF that can be helpful in providing alternate
paths for the specific case of call signaling. The first is [10], paths for the specific case of call signaling. The first is [10],
which is focused on network layer routing and describes a framework which is focused on network layer routing and describes a framework
for enhancements to the LDP specification of MPLS to help achieve for enhancements to the LDP specification of MPLS to help achieve
fault tolerance. This in itself does not provide alternate path fault tolerance. This in itself does not provide alternate path
routing, but rather helps minimize loss in intradomain connectivity routing, but rather helps minimize loss in intradomain connectivity
when MPLS is used within a domain. when MPLS is used within a domain.
skipping to change at page 20, line 10 skipping to change at page 20, line 19
6. Security Considerations 6. Security Considerations
Information on this topic is presented in sections 2 and 4. Information on this topic is presented in sections 2 and 4.
7. References 7. References
This is an informational document. The following are Informative This is an informational document. The following are Informative
References, and there are no Normative References. References, and there are no Normative References.
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "Intellectual Property Rights in IETF Technology",
9, RFC 2026, October 1996. BCP 79, RFC 3668, February 2004
2 Braden, R., et. al., "Integrated Services in the Internet 2 Braden, R., et. al., "Integrated Services in the Internet
Architecture: An Overview", Informational, RFC 1633, June 1994. Architecture: An Overview", Informational, RFC 1633, June 1994.
3 Braden, R., et. al., "Resource Reservation Protocol (RSVP) 3 Braden, R., et. al., "Resource Reservation Protocol (RSVP)
Version 1, Functional Specification", Proposed Standard, RFC Version 1, Functional Specification", Proposed Standard, RFC
2205, Sept. 1997. 2205, Sept. 1997.
4 Shenker, S., et. al., "Specification of Guaranteed Quality of 4 Shenker, S., et. al., "Specification of Guaranteed Quality of
Service", Proposed Standard, RFC 2212, Sept 1997. Service", Proposed Standard, RFC 2212, Sept 1997.
skipping to change at page 23, line 5 skipping to change at page 23, line 13
41 Meyers, D., "Some Thoughts on CoS and Backbone Networks" 41 Meyers, D., "Some Thoughts on CoS and Backbone Networks"
http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf
IETF Presentation: IEPREP, Dec, 2002 IETF Presentation: IEPREP, Dec, 2002
42 Huston, G., "Commentary on Inter-Domain Routing In the Internet", 42 Huston, G., "Commentary on Inter-Domain Routing In the Internet",
Informational, RFC 3221, December 2001. Informational, RFC 3221, December 2001.
43 Baugher, M, et. al., "The Secure Real-Time Transport Protocol 43 Baugher, M, et. al., "The Secure Real-Time Transport Protocol
(SRTP)", Proposed Standard, RFC 3711, March, 2004. (SRTP)", Proposed Standard, RFC 3711, March, 2004.
44 Davie, B., et. al., "An Expedited Forwarding PHB (Per-Hop
Behavior)", Proposed Standard, RFC 3246, March, 2002.
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.
skipping to change at page 24, line 49 skipping to change at page 25, line 18
FROM H235-SECURITY-MESSAGES; FROM H235-SECURITY-MESSAGES;
CallPriorityInfo::= SEQUENCE CallPriorityInfo::= SEQUENCE
{ {
priorityValue CHOICE priorityValue CHOICE
{ {
emergencyAuthorized NULL, emergencyAuthorized NULL,
emergencyPublic NULL, emergencyPublic NULL,
high NULL, high NULL,
normal NULL, normal NULL,
...
}, },
priorityExtension INTEGER (0..255) OPTIONAL, priorityExtension INTEGER (0..255) OPTIONAL,
tokens SEQUENCE OF ClearToken OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL,
cryptoTokens SEQUENCE OF CryptoToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoToken OPTIONAL,
rejectReason CHOICE rejectReason CHOICE
{ {
priorityUnavailable NULL, priorityUnavailable NULL,
priorityUnauthorized NULL, priorityUnauthorized NULL,
priorityValueUnknown NULL, priorityValueUnknown NULL,
...
} OPTIONAL, -- Only used in CallPriorityConfirm } OPTIONAL, -- Only used in CallPriorityConfirm
...
} }
The advantage in using the GenericData parameter is that an existing The advantage in using the GenericData parameter is that an existing
parameter is used, as opposed to defining a new parameter and causing parameter is used, as opposed to defining a new parameter and causing
subsequent changes in existing H.323/H.225 documents. subsequent changes in existing H.323/H.225 documents.
10. Acknowledgments 10. Acknowledgments
The authors would like to acknowledge the helpful comments, opinions, The authors would like to acknowledge the helpful comments, opinions,
and clarifications of Stu Goldman, James Polk, Dennis Berg, Ran and clarifications of Stu Goldman, James Polk, Dennis Berg, Ran
skipping to change at page 25, line 36 skipping to change at page 26, line 13
rifications of the SG16 draft contribution. rifications of the SG16 draft contribution.
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
k.carlberg@cs.ucl.ac.uk I.Brown@cs.ucl.ac.uk
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
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) ..... 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. Considerations ................................................ 6 3. Considerations ................................................ 6
4. Protocols and Capabilities .................................... 7 4. Protocols and Capabilities .................................... 7
4.1 Signaling & State Information ................................ 7 4.1 Signaling & State Information ................................ 7
4.1.1 SIP ........................................................ 7 4.1.1 SIP ........................................................ 8
4.1.2 Diff-Serv .................................................. 8 4.1.2 Diff-Serv .................................................. 8
4.1.3 Variations Related to Diff-Serv and Queuing ................ 9 4.1.3 Variations Related to Diff-Serv and Queuing ................ 9
4.1.4 RTP ........................................................ 9 4.1.4 RTP ........................................................ 10
4.1.5 GCP/H.248 .................................................. 11 4.1.5 GCP/H.248 .................................................. 11
4.2 Policy ....................................................... 11 4.2 Policy ....................................................... 11
4.3 Traffic Engineering .......................................... 12 4.3 Traffic Engineering .......................................... 12
4.4 Security ..................................................... 13 4.4 Security ..................................................... 13
4.4.1 Denial of Service ........................................... 13 4.4.1 Denial of Service ........................................... 13
4.4.2 User authorization .......................................... 14 4.4.2 User authorization .......................................... 14
4.4.3 Confidentiality and integrity ............................... 15 4.4.3 Confidentiality and integrity ............................... 15
4.5 Alternate Path Routing ....................................... 15 4.5 Alternate Path Routing ....................................... 15
4.6 End-to-End Fault Tolerance ................................... 16 4.6 End-to-End Fault Tolerance ................................... 16
5. Key Scenarios ................................................. 17 5. Key Scenarios ................................................. 17
6. Security Considerations ....................................... 19 6. Security Considerations ....................................... 20
7. References .................................................... 20 7. References .................................................... 20
8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 23 8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 23
8.1 GTPS and the Framework Document .............................. 23 8.1 GTPS and the Framework Document .............................. 23
9. Appendix B: Related Standards Work ............................ 23 9. Appendix B: Related Standards Work ............................ 24
9.1 Study Group 16 (ITU) ......................................... 24 9.1 Study Group 16 (ITU) ......................................... 24
10. Acknowledgments .............................................. 25 10. Acknowledgments .............................................. 25
11. Author's Addresses ........................................... 25 11. Author's Addresses ........................................... 26
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society 2003. All Rights Reserved. This Copyright (C) The Internet Society (2004). This document is subject
document and translations of it may be copied and furnished to oth- to the rights, licenses and restrictions contained in BCP 78, and
ers, and derivative works that comment on or otherwise explain it or except as set forth therein, the authors retain all their rights.
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be Disclamer
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided as an This document and the information contained herein is provided as an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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