Internet Draft James M. Polk
Expiration: September 8, 2000 Cisco Systems
File: draft-polk-sip-mlpp-mapping-00.txt
SIP Precedence mapping to MLPP Interworking
March 7, 2000
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 Engi-
neering 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 at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC-2119].
Polk draft-polk-sip-mlpp-mapping-00.txt Page 1
Internet Draft SIP mapping to MLPP March 2000
Abstract
This document describes an extension to the Session Initiation
Protocol [1] for direct interworking and interoperability with
TDM-based Multi-Level Precedence and Preemption [2] Service
Capability networks. This document will further include
details and similar mechanisms to evolve and/or replace
existing TDM-based MLPP network topologies with SIP-based
Voice Signaling topologies with no loss of capability. Al-
though additional mobility and capabilities can easily be
realized with this complete topology architecture implemented.
The author believes these additional Prioritization and
Preemption capabilities will have wider deployment benefits
without direct connectivity to MLPP networks.
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents. . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2.0 MLPP Overview. . . . . . . . . . . . . . . . . . . . . . 3
3.0 Objective of ANSI's MLPP specification . . . . . . . . . 4
4.0 Requisites from ANSI's MLPP Specification. . . . . . . . 4
5.0 Defined SIP Priority request-header field. . . . . . . . 6
6.0 Merging Priority Value Sets. . . . . . . . . . . . . . . 7
7.0 Results of MLPP Extensions to SIP Priority Field . . . . 9
8.0 IANA Considerations . . . . . . . . . . . . . . . . . . 10
9.0 Security Considerations. . . . . . . . . . . . . . . . . 10
10.0 References. . . . . . . . . . . . . . . . . . . . . . . 11
11.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . 11
12.0 Author Information. . . . . . . . . . . . . . . . . . . 11
Polk draft-polk-sip-mlpp-mapping-00.txt Page 2
Internet Draft SIP mapping to MLPP March 2000
1.0 Introduction
This document describes an extension to the Session Initiation
Protocol [1] for direct interworking and interoperability with
TDM-based Multi-Level Precedence and Preemption (MLPP) [2]
Service Capability networks. This document will further include
details and similar mechanisms to evolve and/or replace exist-
ing TDM-based MLPP network topologies with SIP-based Voice
Signaling topologies with no loss of capability; although addi-
tional mobility and capabilities can easily be realized with
this complete topology architecture implemented.
The author believes these additional Prioritization and Pre-
emption capabilities will have wider deployment benefits with-
out direct connectivity to MLPP networks.
2.0 MLPP Overview
Multi level Precedence and Preemption [2] Service Capability
stipulates a relative priority ranking order of Call flows
on a hop-by-hop basis through a Voice Network from their
relative beginning Voice device to the end Voice device.
Within the TDM world, these call flows were closed network
circuit switched from PBX or Tandem Switch to PBX or Tandem
Switch. Each Switch, upon initiation of a higher priority call
flow where there were not available outbound resources or
trunks, preempted a lesser priority call flow by seizing the
resources of an existing external truck circuit to satisfy
that higher Priority Call. Eliminating the previous call with-
out giving either end station a choice or chance to continue
the call flow of the overridden call. Typically, an audible
tone [defined in 2] occurred on the inbound caller's phone
receiving the Preempting call flow.
By contrast, in a Packetized Voice Network, there will likely
not be fixed or pre-configured outbound circuits waiting for
higher priority call flows to occur on a per-MLPP-enabled IP
Internetworking device basis. This presents a more challenging
problem of preemption in a less statically configured Network
Topology.
SIP per [1] created a Priority Header-Field as a non-mandatory
field within the signaling set-up. This document recommends
that this capability be included in all implementations of SIP
devices, even if not enabled. Further, this document recommends
the ability to make the Header-Field "Priority:" mandatory
within an Administrator's Domain if they choose, for all SIP
based call signaling devices. In this scenario, a SIP device
that doesn't have this value present will be denied access to
the invite request.
Polk draft-polk-sip-mlpp-mapping-00.txt Page 3
Internet Draft SIP mapping to MLPP March 2000
3.0 Objective of ANSI's MLPP Specification
The MLPP concept was created so that there was a real-time
method of prioritizing voice communications. It was created
back before electronic switching in the U.S. Government
"AUTOVON" network. It is designed so that normal telephone
traffic would not cause problems in the event of a crisis.
Here is an example using Military Rank as a conceptual com-
parison:
The lowest level, ROUTINE, would be used for all normal call
traffic. If a Company commander needed to reach his platoon
leaders, he/she would use the PRIORITY precedence level. If a
crisis arose, normal traffic would be preempted by command
traffic. The lower level command traffic would use the PRIORITY
and potentially the IMMEDIATE precedence levels. The field
grade traffic (brigade, battalion, and division) would use
the IMMEDIATE, and in some cases FLASH precedence levels.
Communications within the Corps and Theater commanders would
use FLASH. The President, the Joint Chiefs, and some select
theater commanders (e.g. CICNORAD, or CICSAC) would use the
FLASH OVERRIDE precedence. This guaranteed (in theory) that
the most important commands (the President forbidding nuclear
launch) would get through even over all other traffic.
This pre-grading of importance is a method of assigning maximum
levels of priority to traffic based on user Profile (e.g. what
they are authorized to do). Someone who was authorized to use
IMMEDIATE precedence would normally use ROUTINE unless there
was a legitimate reason to escalate the precedence to a higher
level.
4.0 Requisites from ANSI's MLPP Specification [2]
ANSI T.619-1992 states the 5 levels of Precedence (or
Priority) for MLPP networks as the following:
bits Name
---- ----
0000 "Flash Override" (0)
0001 "Flash" (1)
0010 "Immediate" (2)
0011 "Priority" (3)
0100 "Routine" (4)
0101 to
1111 "Spare"
Polk draft-polk-sip-mlpp-mapping-00.txt Page 4
Internet Draft SIP mapping to MLPP March 2000
There are actually 16 values/levels possible within this spec,
but any additional levels will have a preemption functionality
below, or less than, "Routine". The intent is that "Flash
Override" is always the highest level capable within a MLPP-
compliant network.
In any case, a call session of any given Precedence level or
value can preempt any Precedence level of a lesser level or
value. If these values are equal, then other mechanisms, if
any, can react according to their individual capabilities
(e.g. Call waiting).
Preemption can take one of two forms. First, the called party
may be busy with a lower Precedence call which must be pre-
empted in favor of completing the incoming higher Precedence
call from the calling party. Second, the network resources
somewhere in between the calling and called party may be satur-
ated with some combination of call sessions of lower Precedence
requested by the calling party and other traffic (data). If the
data traffic is of some lower priority level (perhaps a lower
level of DSCP value), it should receive less priority in order
to allow this higher priority call session to seize outbound
resources. If there is still not enough available outbound
interface resources, then one or more of the lower Precedence
calls shall be preempted to complete the higher Precedence call.
There are three characteristics of preemption:
a) Any party whose connection was preempted (whether that
resource was reused or not) shall receive a distinctive
audible notification. An addition notification can be
provided via some visual indication if possible or
desirable;
b) Any called party of an active call that is being pre-
empted by a higher Precedence call shall be required to
acknowledge the preemption before being connected to
the new calling party, and
c) When there are no idle resources, preemption of the
lowest of these lower level Precedence resources shall
occur;
Any call session can be preempted anytime after the Precedence
value has been established for a call and call clearing has
begun.
If there is a user or SIP device that is configured (somehow
compliant with the parameters within that Administrative Domain
(AD), and outside the scope of this document) to disable the
Polk draft-polk-sip-mlpp-mapping-00.txt Page 5
Internet Draft SIP mapping to MLPP March 2000
ability to be preempted, that user or SIP phone device will
not experience preemption of calls by higher precedence calls,
if the cause of preemption would be due to called party busy
condition (e.g. call waiting is enacted here). However, the
user may still experience preemption of calls due to a lack
of network resources other than the user's own access resources
[2].
Precedence calls that are not responded to by the called party
(e.g. the called party chooses to hang up their phone without
taking the call) may have their phone speaker initialized for
that inbound Precedence call in order to complete the call;
sometimes regardless if this called party wants the Precedence
call [2]. An alternative to this approach could be to have an
'alternate called party' signaled (e.g. that person's admini-
strator). This mechanism would be a per Domain decision, and
not mandatory for SIP-MLPP interworking compliance.
An MLPP call session should automatically be set up with the
lowest precedence level by default, until the user chooses a
level up to their maximum allowed within that Domain.
5.0 Defined SIP Priority request-header field
SIP[1] defines the Priority request-header field and its
possible non-mandatory values in section "6.25 Priority" as
the following (exact text from page 40 of [1]):
" Priority = "Priority" ":" priority-value
priority-value = "emergency" | "urgent" | "normal"
| "non-urgent"
It is RECOMMENDED that the value of "emergency" only be
used when life, limb or property are in imminent danger.
Examples:
Subject: A tornado is heading our way!
Priority: emergency
Subject: Weekend plans
Priority: non-urgent
These are the values of [3], with the addition of
"emergency". "
This author sees no inconsistencies in adding the "Flash
Override" Value with [1].
Polk draft-polk-sip-mlpp-mapping-00.txt Page 6
Internet Draft SIP mapping to MLPP March 2000
6.0 Merging Priority Value Sets
When comparing sections 4.0 and 5.0, the only difference in
the values is this fifth value in MLPP, the Highest Priority
value ("Flash Override"), although each has a subtly different
name associated for the first 4 values, the intended function-
ality appears to be no different. This document recommends
adoption of the MLPP name designation "Flash Override" for
this new Highest Precedence Value in the interests of con-
sistency. This document explicitly requests the 5th MLPP value
("Flash Override") be included from this document, on a
Standards Track requirement, to possibly be folded into a
future RFC revision of [1], unless obsoleted prior to that
time.
7.0 Results of MLPP Extensions to SIP Priority Field
The following are recommendations or requirements for a SIP
Signaling Environment or Domain enabled with MLPP, or a
subset of MLPP, for the purposes of creating a Network where
Voice Sessions have a need for sub-classification within a
Domain's control:
* SIP end-device MUST include the Header-Field "Priority:"
in all Session Signaling, regardless of session's intent
or destination;
* Header-Field "Priority:" MUST be default set to 'Routine'
unless calling user specifies a Domain authorized Higher
Value for that call session;
* User must be authorized to access higher priority values
for any Higher Precedence call (method of authorization
is outside the scope of this document);
* MUST allow Administrator to make it mandatory for any SIP
receiving device to be MLPP-enabled (goal to have any
non-MLPP device not able to engage in any call session -
in a MLPP environment, this capability should be required
of all devices by that Domain's Administrator)
* Otherwise call isn't established with the following op-
tional (rough language) results:
Polk draft-polk-sip-mlpp-mapping-00.txt Page 7
Internet Draft SIP mapping to MLPP March 2000
* Automated attendant stating to caller "remote device
not MLPP-enabled... call cannot be completed" - call
gets either fast-busy or new tone indicating bad
remote device called;
* Automated attendant stating caller "remote device not
MLPP-enabled... do you wish to proceed with non-pri-
oritized call anyway"
* Simply fast busy
* SIP Gateways within MLPP-enabled Domain MUST have direct
mapping of ISDN Signaling according to [2 and 5];
* It is believed COPS should be utilized for mid-session
path rejections due to congestion, when a Higher Prece-
dence Call session is requesting resources, but that
mechanism is currently outside of the scope of this
document, but might be more detailed in a future version
of this I-D;
8.0 IANA Considerations
This author doesn't believe there are any within this document.
9.0 Security Considerations
It can be argued that Authentication and Authorization of Call
Sessions will not require any security mechanisms until Pri-
ority, Precedence and Preemption are enabled within a network
Domain. Once any or each of these are implemented within a
Domain Network, Security considerations could become signifi-
cantly more important to that Domain.
In an MLPP-enabled Domain, unauthorized setting of any Higher
Priority session should have a great impact on other traffic
unless there is no congestion occurring at any point within the
network, at any time. This author believes Security and Encryp-
tion will become very important within Packetized Voice Communi-
cations in the near future.
Since [2] mandates that each MLPP be defined and (relatively)
closed in nature, boundary controls can and should be possible.
Polk draft-polk-sip-mlpp-mapping-00.txt Page 8
Internet Draft SIP mapping to MLPP March 2000
10.0 References:
[1] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "SIP:
Session Initiation Protocol" RFC 2543, March 1999
[2] ANSI specification ANSI T1.619-1992.
[3] Palme, J., "Common Internet message headers", RFC 2076,
February 1997.
[4] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. (section
3.5 and Appendix B)
[5] ANSI specification ANSI T1.619A-1994.
[6] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding
PHB" RFC 2598, June 1999
11.0 Acknowledgments
A couple of people have made comments and suggestions contribu-
ting to this document. In particular, this author would like
to thank Bob Bell and Rohan Mahy of Cisco Systems.
12.0 Author Information
James M. Polk
Cisco Systems
18581 N. Dallas Parkway, Suite 100
Dallas, TX 75287
jmpolk@cisco.com
"Copyright (C) The Internet Society (date). 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
Polk draft-polk-sip-mlpp-mapping-00.txt Page 9
Internet Draft SIP mapping to MLPP March 2000
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 organi-
zations, 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.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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."
The Expiration date for this Internet Draft is:
September 8, 2000
Polk draft-polk-sip-mlpp-mapping-00.txt Page 10
Internet Draft SIP mapping to MLPP March 2000