Internet Engineering Task Force Mike Pierce
INTERNET DRAFT Artel
Expires October, 2002
Don Choi
DISA
April 2002
Examples for Provision of Preferential Treatment in Voice over IP
draft-pierce-sipping-pref-treat-examples-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed a
http://www.ietf.org/ietf/lid-abstracts.text
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) Internet Society 2001. All rights reserved.
Pierce Expires October 2002 Page 1
Internet Draft Examples of Preferential Treatment in VoIP April 2002
Reproduction or translation of the complete documents, but not of
extracts, including this notice, is freely permitted.
Abstract
Assured Service refers to the set of capabilities used to ensure that
mission critical communications are setup and remain connected.
[Pierce1] describes the requirements, one of which is to provide
preferential treatment to higher priority calls. This memo describes
some of the methods which may be applied to provide that preferential
treatment.
This is intended as an informational memo.
Table of Contents
0. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Potential Preferential Treatments . . . . . . . . . . . . 3
3.1 Reservation of Network Resources . . . . . . . . . . . . . 4
3.1.1 RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Use of Higher Call Acceptance Limits . . . . . . . . . . . 5
3.3 Preferential Queuing of Signaling Messages . . . . . . . . 6
3.4 Preferential Queuing of User Data Packets . . . . . . . . 6
3.5 Discarding of Packets . . . . . . . . . . . . . . . . . . 7
3.5.1 Use of DiffServ . . . . . . . . . . . . . . . . . . . . 7
3.5.2 Mapping for Voice Packets . . . . . . . . . . . . . . . 8
3.5.3 Mapping for Signaling Packets . . . . . . . . . . . . . 9
3.6 Preemption of One or More Existing Calls . . . . . . . . . 9
3.7 Preemption of Some of the Resources Being Used . . . . .. .9
3.8 Preemption of the Reservation . . . . . . . . . . . . . . 10
3.9 Others . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
0. Changes
-00 Initial version based on material removed from draft-pierce-
sipping-assured-service-01.
1. Introduction
[Pierce1] defines the requirements for Assured Service in support of
networks requiring precedence treatment for certain calls, such as
the US military network. One of those requirements is Preferential
Pierce Expires October 2002 Page 2
Internet Draft Examples of Preferential Treatment in VoIP April 2002
treatment, which is the following:
It must be possible to provide preferential treatment to higher
precedence calls in relation to lower precedence calls. Examples
of preferential treatments are:
- reservation of network resources for precedence calls
- usage of higher Call Acceptance limits for higher precedence
calls
- preferential queuing of signaling messages based on
precedence level
- preferential queuing of user data packets based on precedence
level
- discarding of packets of lower precedence call
- preemption of one or more existing calls of lower precedence
level
- preemption of some of the resources being used by a call of
lower precedence level
- preemption of the reservation of resources being held for
other traffic
This informational memo describes some ways in which the above listed
preferential treatments may be provided by utilizing current or new
capabilities.
2. Background
The requirement for Precedence Level Marking of a call setup attempt
is met by the use of the Resource Priority header defined in [Polk2].
The value carried in this header represents the relative precedence
level of the call, and is used to control any of the following
described procedures for providing Preferential Treatment.
3. Potential Preferential Treatments
The requirement to provide preferential treatment to calls may be met
by applying any combination of the following procedures:
3.1 Reservation of Network Resources
This procedure involves pre-reserving certain network resources
during periods when no higher precedence traffic is present so as to
be prepared to handle a given level of high precedence traffic in the
case of an emergency. While this method is already used in the
Pierce Expires October 2002 Page 3
Internet Draft Examples of Preferential Treatment in VoIP April 2002
circuit switched environment, it is less than desirable since it
requires a tradeoff between the amount of wasted resources during
non-emergency periods and the amount of emergency traffic which can
be handled using those reserved facilities.
IETF defined QoS mechanisms for packet-mode operation offer some
improvement to this situation by allowing the amount of reserved
resources to be adjusted.
3.1.1 RSVP
RSVP may be used to establish multiple trunk groups between switching
points, with each trunk group serving a different precedence level of
calls. Each trunk group would be sized based on the number of
simultaneous calls of that precedence level to be supported. (In this
context, a trunk group refers to a facility which can support a
certain number of voice connections at a certain Quality of Service
level. As noted later, the number of connections can be increased
with a corresponding decease in the QoS level.)
With TE, the reserved sizes of these trunk groups could be adjusted
during times of emergency.
No preemption of these trunk groups is needed. However, reducing the
size of a group to near zero would prevent further calls from using
it while allowing existing calls to continue.
3.1.2 MPLS
MPLS may be used to establish the equivalent of dedicated trunk
groups between switching entities, enterprise network, etc. Each of
these "trunk groups" could exist to support a specific precedence
level of traffic between two points and could be setup using the
procedures defined in [RFC3212] or those in [RFC3209]. These support
the signaling of the required five levels of precedence.
3.1.2.1 Constraint-based LSP Setup using LDP
[RFC3212] defines an extension to LDP to provide a constraint-based
routing using MPLS. One of the constraints is based on the notion of
a "priority" level for the new setup. It includes the signaling of a
setup priority and a holding priority with the value of each being 0-
7 (0 is the highest priority). When setting up an LSP as a trunk
group to carry the traffic of one of the expected precedence levels
defined in [Pierce1], the following mapping would be used:
+ ------------------------------------------+
| Assured Service | RFC3212 Preemption TLV |
| Precedence |------------------------|
| Level | SetPrio | HoldPrio |
|------------------+-----------+------------|
| Routine | 4 | 0 |
| Priority | 3 | 0 |
Pierce Expires October 2002 Page 4
Internet Draft Examples of Preferential Treatment in VoIP April 2002
| Immediate | 2 | 0 |
| Flash | 1 | 0 |
| Flash Override | 0 | 0 |
+ ------------------------------------------+
This mapping prevents any preemption of a trunk group for the
establishment of another. Rather, it is expected that trunk groups
for all precedence levels would be initially created and remain. Only
their allocated size might be changed.
If actual preemption were desired, the appropriate HoldPrio values
would be used.
3.1.2.2 RSVP-TE: Extensions to RSVP for LSP Tunnels
As an alternative to LDP, [RFC3209] defines the use of RSVP with
extensions to perform the label distribution for MPLS. It also
includes the same setup and holding priorities as defined in
[RFC3212]. When using RSVP as the label distribution protocol, the
same mapping shown above for LDP would be used.
3.2 Use of Higher Call Acceptance Limits
One aspect of preferential treatment may be provided, without
resorting to preemption of calls, by allowing higher precedence calls
to be setup even when they result in exceeding the engineered traffic
limit on a facility (on an MPLS LSR, for example).
For example, the limits for call acceptance for new calls could be
set as depicted in the following table, where the engineered capacity
of a route or facility is "x". A new call of each precedence level
would be allowed only if the current load is within the limit shown:
+------------------------------+
| Precedence Level | Capacity |
| | limit of |
|------------------+-----------|
| Routine | .9x |
| Priority | x |
| Immediate | 1.1x |
| Flash | 1.3x |
| Flash-override | 1.4x |
+------------------------------+
Explanation of table: In this example, a new Flash call is allowed to
be setup if the current traffic load for all traffic on the facility
is less than 1.3x. In the example shown in this table, Routine
traffic is always prevented from using the last 10% of the capacity.
The choice of the multipliers would be based on an analysis of the
tradeoff between getting the high precedence level call through vs.
sacrificing of QoS. It would depend on the voice encoding algorithms
typically used and the end user expectations.
Pierce Expires October 2002 Page 5
Internet Draft Examples of Preferential Treatment in VoIP April 2002
This procedure is based on a requirement that Flash override calls
should "never" be blocked. (In a probability-based system, there is
no such thing as "never".) In the circuit-switched environment this
could only be guaranteed by having as many circuits as there might be
Flash override calls. For IP-based service, there is no fixed number
of "circuits" on any facility. The "x" referred to above is only an
engineering limit based on a guarantee for the provision of a certain
QoS for normal traffic, i.e., Routine and Priority. This "x" may be
thought of as the number of "circuits" for normal traffic. It is
preferable to allow the setup of additional higher precedence calls
with reduced QoS rather than blocking their setup. For example, while
a particular facility may support 100 normal calls (Routine and
Priority) at the guaranteed QoS, it might support 140 flash-override
calls at a reduced, yet acceptable, QoS (due to packet loss) when in
an emergency situation.
Since the packet preferential treatment using Diff-Serv described in
Section 3.4 and 3.5 could result in the discard or loss of the
packets for the lower precedence calls, the higher precedence calls
could still be provided a sufficient QoS even though they may have
caused the engineered capacity of the route to be exceeded. The lower
precedence calls will then experience higher packet discard rates or
queuing delay times. If the discard rate or delay for these lower
precedence calls is excessive, the end user will experience poor QoS
and will likely disconnect, thereby freeing up the resources.
This "encouraged disconnect" may be thought of as a "graceful
preemption".
3.3 Preferential Queuing of Signaling Messages
There is no plan to apply preferential queuing of signaling messages,
just as this was not done in the circuit switched network. No
advantage can be shown for such a procedure.
3.4 Preferential Queuing of User Data Packets
Rather than utilizing a single class of EF (with one queue) with
multiple levels of drop precedence (with DiffServ) as described in
the following section, priority queuing (and transmission) of packets
based on the precedence level of the call may be used.
As noted in the Appendix in RFC 3246, it is acceptable to provide
multiple instances of EF with different priorities. This would
require assignment of different DSCP values and definition of the
priority handling characteristics for each, resulting in priority
queuing and transmission of the packets for higher precedence calls.
This might be implemented as:
- a single queue with voice packets for higher precedences calls
placed ahead of those of lower precedence calls
- one queue per EF class, with an appropriate transmission scheduling
Pierce Expires October 2002 Page 6
Internet Draft Examples of Preferential Treatment in VoIP April 2002
algorithm and an appropriate discard algorithm in case of queue
overflow.
Since the packets for lower precedence calls would tend to be lost or
delayed more and thereby experience more delay variation, these calls
would experience worse QoS and would be more likely to release.
3.5 Discarding of Packets
3.5.1 Use of DiffServ
Within DiffServ, Assured Forwarding [RFC2597] provides four classes
and three drop precedences for each class (12 DSCP code points). One
of these classes would be used for the signaling messages for session
establishment and release.
Expedited Forwarding [RFC3246] defines a single class (DSCP code
point) and operation, but does not include multiple drop precedences
as AF does. The intention of EF is to "provide low loss, latency and
jitter" and is understood to be intended for traffic such as speech,
although RFC 3246 does not explicitly mention speech or voice.
However, speech is less susceptible to loss than the signaling
traffic and, under some traffic situations, will constitute a much
larger portion of the overall load. Therefore, multiple drop
precedences to alleviate overload are more appropriate to EF than
they are to AF.
The result of this use of DiffServ classes is that voice packets are
always given priority over the signaling packets and all voice
packets are treated the same. While this is the desired behavior in
many cases, it is not desired in those cases in which a limited sized
facility could become completely occupied by voice traffic (using
EF). In this situation, further signaling messages (using AF),
including those to setup new high precedence calls and those to
release low precedence calls, would be lost or excessively delayed.
Therefore, it is necessary to reserve a small capacity for use by the
AF class which serves the signaling traffic as described in Section
2.10 of RFC 3246.
For that portion of the capacity using EF for voice, the required
preferential treatment for the five traffic precedence levels may be
provided by the use of five drop precedence (probability) levels for
packets. The procedures for the interworking of these drop precedence
levels would be the same as defined currently for AF [RFC2597].
Five such levels are necessary to provide the required functionality.
In the absence of "standardized" values, local values will be
assigned. Based on the definitions for AF, these levels are referred
to here as:
Pierce Expires October 2002 Page 7
Internet Draft Examples of Preferential Treatment in VoIP April 2002
- Very low (i.e., lowest probability of being dropped)
- Low
- Medium
- High
- Very high (i.e., highest probability of being dropped)
The following possible mapping is shown to illustrate the concept of
using DiffServ codepoints to assist in the provision of preferential
treatment to the individual packets which make up the information
transfer (connection setup and voice transfer) of an Assured Service
call.
3.5.2 Mapping for Voice Packets
For each of the five precedence levels which may be signaled by the
originator, a mapping takes place to each of the components involved
in the call. This includes the call setup/disconnect signaling and
transfer of the packets carrying the user's data (voice).
This example is for the case of the use of DiffServ to provide the
packet forwarding preferential treatment through multiple drop
precedence levels. Each packet containing a set-up message or user
data (voice) is marked with the following DiffServ codepoint:
+--------------------------------------------------------+
| Precedence | Indication in | Indication in user |
| Level | signaling messages | voice packets |
| |--------------------+--------------------|
| | Class | Drop | Class | Drop |
| | | precedence | | precedence |
|--------------+-------+------------+-------+------------|
|Routine | AFx | Low | EF | Very high |
|Priority | AFx | Low | EF | High |
|Immediate | AFx | Low | EF | Medium |
|Flash | AFx | Low | EF | Low |
|Flash Override| AFx | Low | EF | Very low |
+--------------------------------------------------------+
All voice traffic is then served by a single instance of EF, and
served by a single queue. This results is an equal treatment in terms
of delay variation (often called "jitter") for all precedence levels
for those packets which are delivered, but achieves this by selective
packet discard. The discard may use simple tail dropping or a "Random
Early Detection" algorithm as described in [Moore].
3.5.3 Mapping for Signaling Packets
Consideration could also be given to utilization of different drop
precedences for the signaling messages of different precedence
sessions. However, using SS#7 in the PSTN as a basis, it might also
be meaningful to provide different drop precedences based on type of
message rather than only based on the precedence of the call. For
example, for routine traffic, those messages which cause the release
Pierce Expires October 2002 Page 8
Internet Draft Examples of Preferential Treatment in VoIP April 2002
of sessions could be given a lower drop precedence than those which
set up new sessions in order to allow such releases to take place
properly under overload conditions. High precedence calls, on the
other hand could use a lower drop precedence level for session setup
messages than those of routine precedence calls. The following table
shows what is defined for SS#7 [T1.111], High Probability of
Completion [T1.631], and MLPP [T1.619] and what might be used for
SIP.
(Note: The highest SS#7 Congestion Priority Level, i.e., "3", is the
last to be dropped during congestion.)
(Refer to draft-ietf-sipping-isup-01, Feb 2002 for mapping of ISUP to
SIP messages.)
+---------------------------------+-----------------------------+
| SS#7 | SIP |
+--------------------+------------+----------------+------------+
| Message | Congestion | Message | Drop |
| | Priority | | Precedence |
| | Level | | Level |
+--------------------+------------+----------------+------------+
| Network management | 3 | | |
| ANM | 2 | 200 OK | low |
| RLC | 2 |(no equivalent?)| - |
| IAM (MLPP) | 1 or 2 | INVITE (AS) | low/medium |
| IAM (HPC) | 1 | INVITE (HPC) | low/medium |
| ACM | 1 | 18x | medium |
| CPG | 1 | 100 Trying/18x | medium |
| REL | 1 | BYE | low |
| IAM (normal) | 0 | INVITE (normal)| high |
| Others | 0 | | |
+--------------------+------------+----------------+------------+
3.6 Preemption of One or More Existing Calls
The procedures described above for use of higher call acceptance
limits and selective discard or priority queuing of voice packets
based on the precedence level of the call reduce or eliminate the
need to perform preemption of existing calls. The statistical nature
of packet transmission makes it possible to "squeeze" an additional
high precedence call into an already "full" facility. It should be
noted that, in the extreme case, these procedures would result in the
same effect as preemption, since the resources of the lower
precedence call would be so severely degraded (via packet loss) that
communication would be impossible and the users would disconnect.
When interworking with circuit switched portions of the
telecommunications network, preemption procedures are still required.
3.7 Preemption of Some of the Resources Being Used
The "preemption" of some of the resources being used by lower
Pierce Expires October 2002 Page 9
Internet Draft Examples of Preferential Treatment in VoIP April 2002
precedence traffic may be accomplished through the packet discard or
priority queuing described above.
3.8 Preemption of the Reservation
Based on traffic engineering, the resources allocated to reserved
paths (e.g., MPLS or RSVP) could be adjusted. For example, when an
emergency situation occurs, the need for more resources to support
higher priority traffic could be recognized. The existing LSPs could
be changed using the procedures of [RFC3214] to allow the size of
those LSPs supporting the higher priority traffic to be increased
while others are decreased.
3.9 Others
There may be other procedures which could be used to provide the
required preferential treatments.
4. Security Considerations
The security considerations are covered in [Pierce1].
5. IANA Considerations
It is not expected that there will be any IANA involvement in support
of provision of Preferential Treatment for Assured Service beyond
what is described in [Polk2].
6. References
[RFC2205] "Resource ReSerVation Protocol (RSVP)", September 1997
[RFC2597] "Assured Forwarding PHB Group", June 1999.
[RFC3246] "An Expedited Forwarding PHB", March 2002.
[RFC2751] "Signaled Preemption Priority Policy Element", January
2000.
[RFC3209] "RSVP-TE: Extensions to RSVP for LSP Tunnels", December
2001.
[RFC3212] "CR-LDP: Constraint-based LSP Setup using LDP", January
2002.
[RFC3214] "LSP Modification Using CR-LDP". January 2002.
[T1.111] ANSI T1.111-2001, "Signalling System No. 7 (SS7) - Message
Transfer Part".
Pierce Expires October 2002 Page 10
Internet Draft Examples of Preferential Treatment in VoIP April 2002
[T1.619] ANSI T1.619-1992 (R1999) "ISDN - Multi-Level Precedence and
Preemption (MLPP) Service Capability".
[T1.631] ANSI T1.631-1993 (R1999) "Telecommunications - Signalling
System No. 7 (SS7) - High Probability of Completion (HPC) Network
Capability".
[SIP-2543bis] draft-ietf-sip-rfc2543bis-09, "SIP: Session Initiation
Protocol" (revision), February 2002.
[Pierce1] draft-pierce-sipping-assured-service-02, "Requirements for
Assured Service Capabilities in Voice over IP", April 2002
[Polk2] draft-polk-sipping-resource-00, "SIP Communications Resource
Priority Header", February 2002.
[Moore] draft-ietf-policy-qos-device-info-model-07, "Information
Model for Describing Network Device QoS Datapath Mechanisms",
February 2002.
7. Authors' Addresses
Michael Pierce
Artel
1893 Preston White Drive
Reston, VA 20191
Phone: +1 410.817.4795
Email: pierce1m@ncr.disa.mil
Don Choi
DISA
5600 Columbia Pike
Falls Church, VA 22041-2717
Phone: +1 703.681.2312
Email: choid@ncr.disa.mil
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or 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
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
Pierce Expires October 2002 Page 11
Internet Draft Examples of Preferential Treatment in VoIP April 2002
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY and THE INTERNET ENGINEERING
TASK FORCE disclaim all warranties, express or implied, including but
not limited to any warranty that the use of the information herein
will not infringe any rights or any implied warranties of
merchantability or fitness for a particular purpose.
Internet Draft Examples of Preferential Treatment in VoIP April 2002