Internet DRAFT - draft-pierce-sipping-assured-aervice
draft-pierce-sipping-assured-aervice
Internet Engineering Task Force Mike Pierce
INTERNET DRAFT Artel
Expires May, 2002
Don Choi
DISA
November 2001
Requirements for Assured Service Capabilities in Voice over IP
draft-pierce-sipping-assured-aervice-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.
Reproduction or translation of the complete documents, but not of
extracts, including this notice, is freely permitted.
Pierce Expires May 2002 [Page 1]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
Abstract
Assured Service refers to the set of capabilities used to ensure that
mission critical communications are setup and remain connected. This
memo describes the need for such capabilities in support of the US
military and government communications requirements. It discusses
possible approaches to the provision of these capabilities within the
framework of SIP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. High Level Requirements . . . . . . . . . . . . . . . . . . 5
4. Functional Requirements . . . . . . . . . . . . . . . . . . 5
4.1 Precedence Level Marking . . . . . . . . . . . . . . . . . . 5
4.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Preferential Treatment . . . . . . . . . . . . . . . . . . . 6
4.4 Diversion if Not Answered . . . . . . . . . . . . . . . . . 6
4.5 Notifications to Preempted Party . . . . . . . . . . . . . . 6
4.6 Acknowledge by Preempted Party . . . . . . . . . . . . . . . 7
4.7 Protection of Signaling Information from Disclosure . . . . 7
5. Current Situation . . . . . . . . . . . . . . . . . . . . . 7
5.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3 IntServ/RSVP . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.5 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Possible Approaches . . . . . . . . . . . . . . . . . . . . 9
6.1 Precedence Level Marking . . . . . . . . . . . . . . . . . . 9
6.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 10
6.3 Preferential Treatment . . . . . . . . . . . . . . . . . . . 11
6.4 Diversion . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.5 Notification to Preempted Party . . . . . . . . . . . . . . 12
6.6 Acknowledge by Preempted Party . . . . . . . . . . . . . . . 12
6.7 Protection of Signaling Information . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . 12
7.1 Authentication of User Access . . . . . . . . . . . . . . . 12
7.2 Security of Signaling Information . . . . . . . . . . . . . 12
7.3 Security of Routing Data . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
ANNEX A Example Mapping of Call Precedence Levels . . . . . . . . 15
Pierce Expires May 2002 [Page 2]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
A.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.2 Packet Forwarding Treatment Using DiffServ . . . . . . . . . 16
A.3 Packet Forwarding Treatment Without DiffServ . . . . . . . . 16
A.4 Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Throughout many decades of evolution of the telephony network and its
supporting protocols, there has been a need to provide special
services to a limited subset of the calls within a network or domain
in order to ensure completion of important calls. Examples of this
need have been in support of emergency traffic for natural disasters,
network restoration traffic, and high priority traffic in a military
network. Provision of the required capabilities with the signaling
protocols and within the switching systems has been defined in a
number of national and international standards, most notably a
service referred to as Multi-Level Precedence and Preemption as
defined in an American National Standard [T1.619] in the US and in
corresponding ITU-T Recommendations [I.255.3, Q.735.3, and Q.955.3].
In addition, a service called High Probability of Completion (HPC)
was defined in [T1.631] and, most recently, an ITU-T Recommendation
defines the requirements for the International Emergency Preference
Scheme (IEPS) [E.106].
Other drafts submitted to the IETF have addressed aspects of MLPP and
IEPS. Some of these are [Polk], which identified some of the
requirements for MLPP within IP, [Folts2] which presents the
functional requirements, features, and objectives for the Emergency
Telecommunications Service (ETS), and [Carlberg] which provides a
framework for IEPS for telephony over IP.
MLPP was the solution to providing Assured Service capabilities
within the circuit switched environment. It is essential that
equivalent Assured Service capabilities are defined and implemented
for the packet-based, connectionless environment of the Internet, and
specifically SIP. Without these capabilities, SIP can not be used for
US military applications, and is less than optimal for many other
government uses.
This memo builds on these references and identifies the specific
requirements for Assured Service capabilities in support of the US
military/government environment. Because of many efforts in the past
to jointly develop requirements and signaling protocols, these
requirements are very similar to the requirements of the military/
government networks of other countries. The term "Assured Service" is
Pierce Expires May 2002 [Page 3]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
used to refer to the required capabilities rather than the previous
terms of MLPP or IEPS, since the envisioned set of capabilities and
protocols to achieve them are not expected to be the same as those
previously defined services.
Although not addressed explicitly by this memo, many of the same
requirements and capabilities may be applied for non-military or
government networks, for example, in support of commercial network
restoration efforts. A presentation in the TEWG at London [Ash]
demonstrated real-life situations from the past in which total
network failures required extensive efforts, presumably including
communication via other unaffected networks, to bring the affected
network back on line. If one considered a situation in which the very
network which had failed was needed to carry the network management
traffic required to get it back on line, it would be hard to imagine
how it could ever be brought back up in the face of overwhelming
customer attempts. Capabilities would be required to give priority to
the network management traffic, even to the extent of blocking all
non-emergency traffic for a period of time.
2. Background
In the circuit switched environment, specific circuits or channels
were used for each call. These were typically 64 kbit/s channels
which were a part of a TDM transmission structure. Later developments
used packet/cell based transport instead of dedicated 64 kbit/s
channels, however, the effect was the same. There was still a
dedicated transport capacity assigned for each call.
Assured Service in the circuit switched environment may be provided
by one or more of the following techniques. Note that the
capabilities included within IEPS [E.106], are included here for
reference but not dealt with further in this memo. They are further
dealt with in [Folts2]:
- Giving priority to return of dial tone (IEPS).
- Marking of signaling messages for better handling, for example,
being last to be dropped in case of congestion in the signaling
network (HPC).
- Extra routing possibilities for higher priority calls. (IEPS)
- Exemption from restrictive management controls (IEPS) such as
hard-to-read codes and code gapping.
- Reservation of specific facilities (trunks) for higher priority
Pierce Expires May 2002 [Page 4]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
traffic (IEPS).
- Higher priority calls may preempt existing lower priority calls,
causing the network to release the lower priority call to free
up resources for immediate reuse by the higher priority call
(MLPP).
Identification of traffic authorized to use one or more of these
techniques may be via the following methods:
- Calls placed from physical lines authorized for its use
- Calls placed to specific telephone numbers or blocks of numbers
- Entry of a special ID code and PIN from any telephone line
3. High Level Requirements
While the existing requirements and capabilities have been developed
with the circuit switched environment in mind, many are directly
applicable to the packet environment and specifically the Voice over
IP application being defined using SIP. Some of the capabilities need
to be adapted or modified for application in the packet mode
environment. In addition, there will likely be new techniques which
can be defined specifically for the SIP case.
At a high level, the Assured Service requirements can be stated as
the need to ensure that mission critical voice-mode calls get set up
and remain connected.
4. Functional Requirements
As noted above, the functional requirements for Assured Service being
detailed here are specifically those needed to support the US
government requirements, primarily for the military environment. This
memo concentrates on those portions mentioned in Section 2 which are
derived from the requirements for MLPP as defined in [T1.619].
The basic requirements can be defined as follows;
4.1 Precedence Level Marking
It must be possible for the originator to select and signal one of
five precedence levels for a call, with the call defaulting to the
lowest if none is specified. It must be possible to carry this call
associated precedence level though the IP network. It must be
Pierce Expires May 2002 [Page 5]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
possible to deliver the originally signaled precedence level to the
called party.
4.2 Authentication
It must be possible to verify that the calling party is authorized to
use the Assured Service and the requested value and to take the
appropriate action if the calling party attempts to use a higher
level. The preferred action is to reject the call, and send an
indication of the reason to the caller.
4.3 Preferential Treatment
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
4.4 Diversion if Not Answered
If a precedence call (one higher that "Routine") does not answer
within a designated time or the called party is busy with a call of
equal or higher precedence such that an indication of the new call
can not be given, the call must be diverted to a predetermined
alternate party. In general, this must operate similar to a normal
"Call Forwarding on No Answer" service.
4.5 Notifications to Preempted Party
All preempted parties must be provided with a distinct notification
informing them that their call has been preempted.
Pierce Expires May 2002 [Page 6]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
4.6 Acknowledge by Preempted Party
When a call is preempted for delivery of a higher precedence call to
the same party, after the party is notified that a new call is being
presented, the party must acknowledge the preemption before the new
call is connected. That is, there must be a positive acknowledgement
before any audio information is transferred in either direction.
4.7 Protection of Signaling Information from Disclosure
It is required that sensitive information not be made available to
non-secure portions of the network or to any non-secure network
through which the traffic passes. It is also important that it not be
accessible by users connected to the network. This non-disclosure
requirement especially applies to information which is used to
control link state routing protocols based on knowledge of the
current traffic load at each precedence level on each route.
Further, it is desirable that the precedence information regarding
each call (as well as the other information such as calling/called
party identity) be protected from disclosure to the greatest extent
possible.
5. Current Situation
Current support for Assured Service within various IETF defined
protocols and ongoing initiatives is not considered to be sufficient.
5.1 IPv4
Although support for the traditional five precedence levels was
included in the TOS field of IPv4 from the earliest days, support for
this field is not universal, and it only provides packet level
priority. It does not provide call setup priority or control of call
retention.
5.2 DiffServ
Although it is possible to map the required five precedence levels to
the Assured Forwarding classes defined in RFC 2597, this also
provides only per packet priority treatment. While this may provide a
fundamental subcomponent of the Assured Service requirements detailed
in this memo, it does not support the basic call setup priority that
is required.
While a mapping could be defined between the required five precedence
levels and the four Assured Forwarding classes, there is no explicit
Pierce Expires May 2002 [Page 7]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
order defined for those AF classes. This would need to be done.
Additionally, the Expedited Forwarding PHB may provide a needed
capability for the transfer of signaling messages for high priority
traffic. On the other hand, it is likely that it will be necessary to
use this PHB for all call control signaling in order to meet any
acceptable delay limit on the transfer of messages for even the
lowest priority calls.
5.3 IntServ/RSVP
Although RSVP includes mention of preemption of existing reservations
in favor of other higher priority ones, it does not provide detailed
procedures for doing so. In principle, it should be straightforward
to do so. However, it is not believed that the procedures required
for establishment of a path using RSVP, and the additional procedures
that would be necessary for preemption of an existing path, would
allow this to be useful for the provision of Assured Service
capabilities to individual calls.
RSVP may be applicable for the establishment of trunk groups between
switching points, with each trunk group serving a different
precedence level of calls. No preemption of these trunk groups is
required.
5.4 MPLS
Since MPLS is fundamentally a means to emulate circuit-mode operation
by establishment of a "path" which then functions like a
"connection", the principles of priority and preemption could be
applied to this path the same as they are in the circuit-mode
environment. RFC 2702 describes the requirements for such
capabilities as applied to "traffic trunks". However, it uses the
term "traffic trunk" to refer to a facility which is established to
carry an aggregate of traffic, i.e., many telephone calls. This is
the equivalent of a "trunk group" in standard telephony terminology
[T1.523]. Because of the extensive procedures that are required to
establish and remove such a Label Switched Path, it is believed that
this prevents MPLS from being used to setup paths for individual
calls.
MPLS may be applicable for the establishment of the equivalent of
dedicated trunk groups between switching entities (if such entities
were to exist in the SIP network architecture). Each of these "trunk
groups" or "traffic trunks" could exist to support a specific
precedence level of traffic between two points and could be setup
using the procedures defined in [MPLS-CR-LDP] or those in [MPLS-RSVP-
LSP]. These drafts allow the signaling of the required five levels of
Pierce Expires May 2002 [Page 8]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
precedence as well as separate setup and holding priorities.
5.5 SIP
The initial plans for SIP [RFC2543] defined four tokens for priority
levels to be used to control call setup, however, they do not equate
to the levels required for Assured Service. It should also be noted
that no explicit ordering of these four defined values (emergency,
urgent, normal, non-urgent) can be found. The current draft revision
[SIP-2543bis] adds the notion of a fifth value or "token" for
"other-priority", but it does not define how this would be used.
While the intention of this addition might be to allow the definition
of whatever tokens are desired in various applications, this does not
provide a standard to ensure interoperability without the additional
burden of a coordination function such as that provided by IANA.
Security is discussed in the draft revision to RFC 2543 [SIP-
2543bis], but it has been recognized in various Working Group
discussions that security for all aspects of call control needs to be
considered in a unified manner. Security for each individual
component of call setup and release can not be designed separately.
The procedure being proposed for authorization of call set-up and
media allocation [SIP-CALL-AUTH] appears to be too time consuming to
expect it to occur each time a user attempts to place a telephone
call, especially a high-priority one. The probable delay in
establishing this authorization would be contrary to the goals and
requirements for Assured Service. Overloads of the proxies
responsible for the Call Authorization would prevent or unacceptably
delay setup of the high precedence call.
6. Possible Approaches
The following identify possible approaches to meeting the
requirements stated above.
6.1 Precedence Level Marking
The approaches to be used for precedence level marking may need to be
different for each of the following cases:
A. Individual call setup:
There needs to be a definition of a field to be carried in SIP which
identifies the precedence levels of 0-4. These five values have
specific meanings within the US military networks (as currently
defined in MLPP) and the standard may reflect these meanings of the
Pierce Expires May 2002 [Page 9]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
values 0-4. However, it is preferable to not use the actual English
language words within the protocol itself, as is currently defined in
the Priority Header in SIP, since other countries will use different
words and interoperability may be difficult.
The specification may allow more than 5 levels. There is no need for
the 65k levels defined in [RFC2751] nor is there currently a
requirement to carry the separate preemption and defending priorities
of [RFC2751] or the separate setup and holding priorities proposed in
[MPLS-CR-LDP] and [MPLS-RSVP-LSP].
B. Packet forwarding:
To support preferential treatment on the packet transfer level, the
currently defined priority levels in IPV4 and the Assured Forwarding
and Expedited Forwarding PHBs of DiffServ will provide the required
functionality. Appropriate mappings from the call level precedence
levels to these PHBs should be defined in BCPs for various networks.
An example of such mapping is provided in Annex A.
C. Trunk group establishment:
For MPLS, RFC 2702 defines the idea of a "traffic trunk" for which a
priority may be signaled by the label distribution protocol in order
to establish telephony "trunk groups". If LDP is used for label
distribution, the priority defined in [MPLS-CR-LDP] should be used.
If RSVP is used for label distribution, the priority defined in
[MPLS-RSVP-LSP] should be used.
6.2 Authentication
There needs to be a simple security mechanism (in the sense that it
requires a few number of messages exchanged between a few number of
network elements) to be used for each call setup. It is essential
that a framework for security for SIP be established that allows a
security association to be established between a user's terminal and
their dedicated SIP proxy at the time of an initial registration.
This initial registration would likely require an extensive number of
messages and interaction with numerous network elements including a
Policy Server. This registration would normally be done when a
terminal is turned on, activated, or places the first call.
Thereafter, the authentication for each call establishment must
consist of a simple exchange of a minimum number of messages between
that user and the dedicated proxy. This should preferably consist of
one message, the same as the one requesting service (INVITE). In many
other cases besides call setup, it is also necessary to perform
authentication. Appropriate security mechanisms have already been
defined to perform an initial registration.
Pierce Expires May 2002 [Page 10]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
This requires that each user have a dedicated proxy to support
originating and terminating calls. It appears that discussions of
other capabilities within SIP are coming to the same conclusion for
provision of other services and capabilities. For examples, [SIP-
PRIVACY] states that, in order for an originating device to achieve
privacy concerning its IP address related information, "UACs ... must
initiate calls through their trusted proxy". In addition, the
terminating UAS also has to operate through a specific trusted proxy.
This association between a user and a proxy would be established at
the time of registration.
6.3 Preferential Treatment
The preferential treatments would not be standardized unless they
require signaling between network elements. Currently, most
treatments envisioned are local matters within a proxy or router.
Consideration of preferential treatments depends on the case:
A. Per call:
Preemption of existing calls will require coordination between
network elements, and therefore protocol standards, especially if
distinct actions are expected to reserve the preempted resources for
setup of the higher precedence call,
B. Packet level:
Current capabilities of DiffServ will provide the necessary
preferential treatments regarding packet transfer, including
indications of priority queuing and discard priority. It is not
envisioned that additional functionality is needed.
C. MPLS/RSVP Paths:
There should be no need for preemption of MPLS/RSVP established
traffic trunks (trunk groups) as described in [RFC2702] and
[RFC2205]. The required capability should be provided by mechanisms
to reduce the traffic engineering limits placed on lower priority
trunk groups (even by reducing to zero) to make space for the
establishment of a new higher priority trunk group or the increasing
of the limits on already existing higher priority trunk groups.
6.4 Diversion
Diversion should be based on procedures that are developed for a Call
Forwarding on No Answer type service. However, it should not be
dependent on a timing performed by the original called party. Again,
Pierce Expires May 2002 [Page 11]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
this must be a function of either the originating or terminating
proxy.
6.5 Notification to Preempted Party
Notification to the preempted party should follow whatever is done
for notifications for any network-initiated release.
6.6 Acknowledge by Preempted Party
Acknowledge by the preempted party (before connection of a new call)
should follow whatever is done for normal call presentation, that is,
it must be acknowledged before any audio is transferred in either
direction. The terminating proxy should probably control the flow of
audio packets.
6.7 Protection of Signaling Information
See Section 7.
7. Security Considerations
7.1 Authentication of User Access
Discussions within SIP are beginning to identify the need to
authenticate all access to capabilities, since virtually any could be
misused, resulting in harm to the network or other users. Because
Assured Service is intended to provide an authorized user with better
service than other users, including the potential of actually
preempting other calls, it is even more important to authenticate the
user's access to the Assured Service capabilities.
7.2 Security of Signaling Information
The need to protect signaling information from disclosure is
independent from the provision of Assured Service. Military/
government networks have long been built on the premise that such
information needed to be protected. Bulk encryption of signaling
links (as well as the user data channels) between secure switches
provided much of this protection. In addition, the Signal Transfer
Points of the SS#7 network could be secured against unauthorized
access. It should be noted that commercial networks are now beginning
to recognize the need for the same protection.
In the IP environment, the signaling packets as well as the user data
traverse many routers and could be accessed by unauthorized persons
at any one of them. While the contents of the individual signaling
Pierce Expires May 2002 [Page 12]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
messages could be hidden by encryption of the request and response
for end-to-end protection of information, the header must be visible
to intermediate routers. It is preferable to not require decryption/
encryption at each router. The approach has been to encrypt the
contents of the signaling message but not the headers which are
needed by the routers. However, the headers themselves may contain
sensitive information such as precedence level and called party
identification.
7.3 Security of Routing Data
Of more concern than the information about an individual call is the
information normally needed by Link State routing logic used by an
originating device to select a route though an entire network. Such a
routing function requires knowledge of the state (busy or not) of
various portions of the network. When Assured Service based on
precedence levels is added, this requires that the routing point also
know the current loading of various precedence levels for each
portion of the network. Especially in a large network, this is highly
sensitive information and must not be revealed to unauthorized
network elements.
It should be noted that the constraint-based LSP setup proposed in
[MPLS-CR-LDP] depends on the routing point knowing this information.
8. IANA Considerations
It is not expected that there will be any IANA involvement in support
of Assured Service. The definition of precedence levels in the
protocol should be of generic, non-application specific values
forming an ordered set, for example 0-15. The meaning of each value,
that is, the words in the local language which represent the level,
is a local matter and need not be a part of the protocol definition.
9. References
[T1.523] ANSI T1.523-2001 Telecommunications Glossary.
[T1.619] ANSI T1.619-1992 (R1999) Multi-Level Precedence and
Preemption (MLPP) Service, ISDN Supplementary Service Description.
[T1.619a] ANSI T1.619a-1994 (R1999) Addendum to MLPP.
[T1.631] ANSI T1.631-1993 (R1999) Telecommunications - Signalling
System No. 7 (SS7) - High Probability of Completion (HPC) Network
Capability.
Pierce Expires May 2002 [Page 13]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
[E.106] ITU-T Recommendation E.106 (2000) International Emergency
Preference Scheme (IEPS).
[I.255.3] ITU-T Recommendation I.255.3 (1990), Multilevel precedence
and preemption service (MLPP).
[Q.735.3] ITU-T Recommendation Q.735.3 (1993), Description for
community of interest supplementary services using SS No. 7 -
Multilevel precedence and preemption (MLPP).
[Q.955.3] ITU-T Recommendation Q.955.3 (1993), Description for
community of interest supplementary services using DSS1 - Multilevel
precedence and preemption (MLPP).
[RFC2205] "Resource ReSerVation Protocol (RSVP)", R. Braden, et al,
Sept 1997
[RFC2597] "Assured Forwarding PHB Group", J. Heinanen, et al, June
1999.
[RFC2598] "An Expedited Forwarding PHB", V. Jacobson, et al, June
1999.
[RFC2702] "Requirements for Traffic Engineering Over MPLS", D.
Awduche, et al, Sept 1999.
[RFC2751] "Signaled Preemption Priority Policy Element", S. Herzog,
January 2000.
[MPLS-CR-LDP] draft-ietf-mpls-cr-ldp-05, "CR-LDP: Constraint-based
LSP Setup using LDP", February 2001. ????
[MPLS-RSVP-LSP] draft-ietf-mpls-lsp-tunnel-08, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", February 2001.
[SIP-CALL-AUTH] draft-ietf-sip-call-auth-02, "SIP Extension for Media
Authorization", August 2001.
[SIP-PRIVACY] draft-ietf-sip-privacy-02, "SIP extensions for Caller
Identity and Privacy", May 2001.
[SIP-2543bis] draft-ietf-sip-rfc2543bis-05, "SIP: Session Initiation
Protocol" (revision), October 2001.
[Ash] draft-ash-mpls-diffserv-te-alternative-02, "Alternative
Technical Solution for MPLS DiffServ TE", Jerry Ash, Aug 2001.
Pierce Expires May 2002 [Page 14]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
[Carlberg] draft-carlberg-ieps-framework-01, "Framework for
Supporting IEPS in IP Telephony", Ken Carlberg, July 2001.
[Folts1] draft-folts-ohno-ieps-considerations-00, "Functional
Requirements for Priority Services to Support Critical
Communications", Hal Folts, June 2000.
[Folts2] draft-folts-ieps-white-paper-00, "Emergency
Telecommunications Service in Next-Generation Networks", Hal Folts,
Oct 2001.
[Polk] draft-polk-mlpp-over-ip-00, "Multi-Level Precedence and
Preemption over IP", James Polk, February 2001.
10. 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
ANNEX A Example Mapping of Call Precedence Levels
A.1 General
For each of the five precedence levels which may be signaled by the
originator, a mapping should take place for 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 based on the presumption of the use of an
audio coding algorithm which includes marking individual packets
which may be considered for discard in case of overload.
Pierce Expires May 2002 [Page 15]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
A.2 Packet Forwarding Treatment Using DiffServ
This example is for the case of the use of DiffServ to provide the
packet forwarding preferential treatment.
-------------------------------------------------------------------
| Precedence |Indication| Indication in user | Indication in user |
| Level |in set-up | data transfer for | data transfer for |
| |messages | packets not marked | packets marked for |
| | | for discard by | discard by codec |
| | | codec | |
| | |-----------------------------------------|
| | | Class | Drop | Class | Drop |
| | | | precedence | | precedence |
|-------------------------------------------------------------------|
|Routine | None | AF1 | Medium | AF1 | High |
|Priority | EF | AF1 | Low | AF1 | Medium |
|Immediate | EF | AF2 | Low | AF2 | Medium |
|Flash | EF | AF3 | Low | AF3 | Medium |
|Flash Override| EF | AF4 | Low | AF4 | Medium |
-------------------------------------------------------------------
A.3 Packet Forwarding Treatment without DiffServ
When the network is not DiffServ capable, the only mapping available
for packet level preferential treatment is the defined priority
values within IPv4 (and their carry-over into IPv6). The same five
call setup precedence levels addressed in this memo are supported by
RFC 791 and the mapping is direct.
A.4 Call Setup
Proper identification of the required five precedence levels for call
setup within SIP will require standardization of the appropriate
values/field within SIP signaling and possibly a BCP for the mapping
that would apply within a specific network.
As an example, presuming a new Header is defined to carry the
Priority Level needed to support Assured Service Call Setup control
and if the tokens representing the levels were defined as:
"Level00" | "Level01" | "Level02" | "Level03" | ... | Level15"
with an explicit statement concerning the order, then the following
mapping could be defined (for a specific network that uses five
levels):
Pierce Expires May 2002 [Page 16]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
Mapping at originating point:
----------------------------------------------
| From: User's desired | To: SIP Header |
| Precedence Level | |
|----------------------------------------------|
| Routine | Level04 |
| Priority | Level03 |
| Immediate | Level02 |
| Flash | Level01 |
| Flash Override | Level00 |
----------------------------------------------
Mapping at terminating point:
----------------------------------------------
| From: SIP Header | To: User's application|
| | |
|----------------------------------------------|
| Level15 - Level04 | Routine |
| Level03 | Priority |
| Level02 | Immediate |
| Level01 | Flash |
| Level00 | Flash Override |
----------------------------------------------
(Other networks may choose to use fewer levels and could use
different words to represent those levels.)
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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
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.
Pierce Expires May 2002 [Page 17]
Internet Draft Requirements for Assured Service in VoIP 14 Nov 2001
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.
Pierce Expires May 2002 [Page 18]
