< draft-polk-sip-mlpp-mapping-00.txt   draft-polk-sip-mlpp-mapping-01.txt >
Internet Draft James M. Polk Internet Draft James M. Polk
Expiration: September 8, 2000 Cisco Systems Expiration: September 2, 2001 Cisco Systems
File: draft-polk-sip-mlpp-mapping-00.txt File: draft-polk-sip-mlpp-mapping-01.txt
SIP Precedence mapping to MLPP Interworking SIP Extension for MLPP
March 7, 2000 March 1, 2001
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engi- Internet-Drafts are working documents of the Internet Engi-
neering Task Force (IETF), its areas, and its working groups. neering Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents Note that other groups may also distribute working documents
as Internet-Drafts. as Internet-Drafts.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC-2119]. interpreted as described in [RFC-2119].
Abstract Abstract
This document describes an extension to the Session Initiation This document describes an extension to the Session Initiation
Protocol [1] for direct interworking and interoperability with Protocol [1] to allow SIP (and IP) into existing Voice Backbone
TDM-based Multi-Level Precedence and Preemption [2] Service Infrastructures that require Multi-Level Precedence and Pre-
Capability networks. This document will further include emption [2] Service throughout those networks. This document
details and similar mechanisms to evolve and/or replace will also allow MLPP networks that are ISDN-based now to evolve/
existing TDM-based MLPP network topologies with SIP-based migrate or be replaced by a SIP-based Voice Signaling network
Voice Signaling topologies with no loss of capability. Al- with no loss in capability of that original network. More likely
though additional mobility and capabilities can easily be is the case that additional functionality and capabilities can
realized with this complete topology architecture implemented. be realized such as mobility and reduced user headaches (ex-
plained later) with SIP being MLPP enabled within a network
infrastructure.
The author believes these additional Prioritization and I believe these additional Precedence and Preemption capabili-
Preemption capabilities will have wider deployment benefits ties will have wider deployment benefits than named MLPP
without direct connectivity to MLPP networks. networks such as the US Government networks.
Table of Contents Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Table of Contents. . . . . . . . . . . . . . . . . . . . . . 2 Table of Contents. . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . 3 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2.0 MLPP Overview. . . . . . . . . . . . . . . . . . . . . . 3 2.0 The need for this Extension vs. incorporation? . . . . . 3
3.0 Objective of ANSI's MLPP specification . . . . . . . . . 4 2.1 Part of a bigger effort? . . . . . . . . . . . . . . . . 4
4.0 Requisites from ANSI's MLPP Specification. . . . . . . . 4 3.0 MLPP Overview. . . . . . . . . . . . . . . . . . . . . . 5
5.0 Defined SIP Priority request-header field. . . . . . . . 6 4.0 Objective of ANSI's MLPP specification . . . . . . . . . 6
6.0 Merging Priority Value Sets. . . . . . . . . . . . . . . 7 5.0 Requisites from ANSI's MLPP Specification. . . . . . . . 7
7.0 Results of MLPP Extensions to SIP Priority Field . . . . 9 6.0 Defined SIP Priority request-header field. . . . . . . . 9
8.0 IANA Considerations . . . . . . . . . . . . . . . . . . 10 7.0 Request Header-Field:MLPP-Enabled Extension . . . . . .10
9.0 Security Considerations. . . . . . . . . . . . . . . . . 10 7.1 A subset of MLPP? . . . . . . . . . . . . . . . . . . .11
10.0 References. . . . . . . . . . . . . . . . . . . . . . . 11 8.0 Results of MLPP Extensions to SIP Priority Field . . . .11
11.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . 11 9.0 Unknowns needing discussion still . . . . . . . . . . .13
12.0 Author Information. . . . . . . . . . . . . . . . . . . 11 9.0 Changes from the last version . . . . . . . . . . . . .14
10.0 IANA Considerations . . . . . . . . . . . . . . . . . .14
11.0 Security Considerations. . . . . . . . . . . . . . . . .14
12.0 References. . . . . . . . . . . . . . . . . . . . . . . 15
13.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . 15
14.0 Author Information. . . . . . . . . . . . . . . . . . . 16
1.0 Introduction 1.0 Introduction
This document describes an extension to the Session Initiation This document describes an extension to the Session Initiation
Protocol [1] for direct interworking and interoperability with Protocol [1] to allow SIP (and IP) into existing Voice Backbone
TDM-based Multi-Level Precedence and Preemption (MLPP) [2] Infrastructures that require Multi-Level Precedence and Pre-
Service Capability networks. This document will further include emption [2] Service throughout those networks. This document
details and similar mechanisms to evolve and/or replace exist- will also allow MLPP networks that are ISDN-based now to evolve/
ing TDM-based MLPP network topologies with SIP-based Voice migrate or be replaced by a SIP-based Voice Signaling network
Signaling topologies with no loss of capability; although addi- with no loss in capability of that original network. More likely
tional mobility and capabilities can easily be realized with is the case that additional functionality and capabilities can
this complete topology architecture implemented. be realized such as mobility and reduced user headaches (ex-
plained later) with SIP being MLPP enabled within a network
infrastructure.
The author believes these additional Prioritization and Pre- I believe these additional Precedence and Preemption capabili-
emption capabilities will have wider deployment benefits with- ties will have wider deployment benefits than named MLPP net-
out direct connectivity to MLPP networks. works such as the US Government networks.
2.0 MLPP Overview 2.0 The need for this Extension vs. incorporation?
As much as I believe this in this capability, I also believe it
should be necessarily a burden for all SIP developers to include.
Therefore, I believe this I-D should be a Standards Track WG
item, but separate for the core 2543bis effort such that those
vendors that wish to develop products into this fairly limited,
yet potentially very large segment, can merely be following
this I-D. I believe this will also help in the IETF Standarding
process of SIP by itself by not being included in the core
effort mandating (I believe) 3 completely interoperable solu-
tions for every feature and specification within the SIP I-D.
An additional reason for this maintaining its name is the
customer driven requirement and comfort-zone of MLPP itself.
An RFP can state fairly clearly that it requires adherence
to RFC-XXXX (SIP Ext. for MLPP) in its bidding between vendors.
This does make it quite a bit easier for that process as well.
I'm also aware of the desire to NOT include everything and the
kitchen sink in the core 2543bis effort.
SIP is, and is well put in [3], "not a PSTN replacement". And
any Priority or Preemption without government intervention is
not allowed (GETS [4] is the best example of this). "SIP is a
Protocol for initiating, modifying, and terminating interactive
sessions" from [3] as well. Which goes on to state the following
that applies directly:
" This process involves the discovery of users, (or more
generally, entities that can be communicated with,
including services, such as VM or translation devices)
wherever they may be located, so that a description of
the session can be delivered to the user."
Sometimes the Signaling for a session will take the same path
the RTP stream will, most times it will not. Although each will
likely take different paths, the specifics of the MLPP call
set-up such as which Precedence level is chosen by the user
needs to start with the calling or session initiating device.
Even though SIP is intended to traverse more than a single
network infrastructure in its creation, MLPP functionality like-
ly will not, but could on a limited basis where strict SLA's or
similar agreements are adhered to. Creating an Extension that is
basically intended for a single network is generally frowned
upon, and I understand. Additionally, extensions that define a
function's usefulness only if all devices support that extension
is also discouraged [3]. However, one of the networks that
requires MLPP adherence before considering IP-based anything
voice session initiation has currently more than 800 Class 5's
operating in that network. The migration to IP will difficult
at best for this one network that has such strict requirements,
and that is the reason for this Extension: adherence to strict
guidelines and capabilities in a "Standards way". I have talked
to a customer representing parts, to all of 19 country's
government networks that are mostly all waiting on MLPP to be
defined in IP in this Standarding Body before moving their
respective networks towards IP. So, the question that I pose to
you is this I-D:
2.1 Part of a bigger effort?
Yes, this I-D is part of a larger IETF effort. I have written an
I-D [5] that attempts to address the non-SIP requirements for
enabling MLPP into an IP network infrastructure. What I propose
here is just what SIP is intended to do: initiate the session
with certain features, capabilities and descriptions in that
session initiation. Relatively speaking, this is easier than
getting the network to behave in a deterministically Preemptive
mode to a customer's satisfaction. It gets more complicated with
inclusion of 'other' services. IM could become MLPP-enabled.
Video certainly could, but traffic engineering then becomes a
problem due to its bandwidth requirements.
Another effort was started at the Pittsburgh meeting, IEPS [4].
It has been suggested that this MLPP effort is the logical pre-
cursor to the IEPS effort. Section 1.2.1 of [4] refers to another
type of PSTN requirement, GETS (Government Emergency Telephone
Service). MLPP could be used as a basis for that requirement
with some user authentication enhancements.
3.0 MLPP Overview
Multi level Precedence and Preemption [2] Service Capability Multi level Precedence and Preemption [2] Service Capability
stipulates a relative priority ranking order of Call flows stipulates a relative priority ranking order of Call flows
on a hop-by-hop basis through a Voice Network from their on a hop-by-hop basis through a Voice Network from their
relative beginning Voice device to the end Voice device. relative beginning Voice device to the end Voice device.
Within the TDM world, these call flows were closed network Within the TDM world, these call flows were closed network
circuit switched from PBX or Tandem Switch to PBX or Tandem circuit switched from PBX or Tandem Switch to PBX or Tandem
Switch. Each Switch, upon initiation of a higher priority call Switch. Each Switch, upon initiation of a higher priority call
flow where there were not available outbound resources or flow where there were not available outbound resources or
trunks, preempted a lesser priority call flow by seizing the trunks, preempted a lesser priority call flow by seizing the
skipping to change at page 3, line 45 skipping to change at page 5, line 40
tone [defined in 2] occurred on the inbound caller's phone tone [defined in 2] occurred on the inbound caller's phone
receiving the Preempting call flow. receiving the Preempting call flow.
By contrast, in a Packetized Voice Network, there will likely By contrast, in a Packetized Voice Network, there will likely
not be fixed or pre-configured outbound circuits waiting for not be fixed or pre-configured outbound circuits waiting for
higher priority call flows to occur on a per-MLPP-enabled IP higher priority call flows to occur on a per-MLPP-enabled IP
Internetworking device basis. This presents a more challenging Internetworking device basis. This presents a more challenging
problem of preemption in a less statically configured Network problem of preemption in a less statically configured Network
Topology. Topology.
SIP per [1] created a Priority Header-Field as a non-mandatory SIP per [1] created a "Header-Field:Priority" as a non-mandatory
field within the signaling set-up. This document recommends field within the signaling set-up (section 6.0 shows this). The
that this capability be included in all implementations of SIP 2543bis I-D [7] added a single Priority Header-Field that is and
devices, even if not enabled. Further, this document recommends for less than normal traffic. Although this creates 5 distinct
the ability to make the Header-Field "Priority:" mandatory Priority levels, it does not satisfy the MLPP semantics require-
within an Administrator's Domain if they choose, for all SIP ments of 5 levels with normal traffic (called 'Routine' by [2])
based call signaling devices. In this scenario, a SIP device at the lowest Priority or Precedence level, escalating to the
that doesn't have this value present will be denied access to highest Priority or Precedence level (called ' Flash Override' in
the invite request. [2]). All this is explained in more detail on the next page in
section 4.0.
3.0 Objective of ANSI's MLPP Specification 4.0 Objective of ANSI's MLPP Specification
The MLPP concept was created so that there was a real-time The MLPP concept was created so that there was a real-time
method of prioritizing voice communications. It was created method of prioritizing voice communications. It was created
back before electronic switching in the U.S. Government back before electronic switching in the U.S. Government
"AUTOVON" network. It is designed so that normal telephone "AUTOVON" network. It is designed so that normal telephone
traffic would not cause problems in the event of a crisis. traffic would not cause problems in the event of a crisis.
Here is an example using Military Rank as a conceptual com- Here is an example using Military Rank as a conceptual com-
parison: parison:
The lowest level, ROUTINE, would be used for all normal call The lowest level, ROUTINE, would be used for all normal call
traffic. If a Company commander needed to reach his platoon traffic. If a Company commander needed to reach his platoon
leaders, he/she would use the PRIORITY precedence level. If a leaders, he/she would use the PRIORITY precedence level. If
crisis arose, normal traffic would be preempted by command a crisis arose, normal traffic would be preempted by command
traffic. The lower level command traffic would use the PRIORITY traffic. The lower level command traffic would use the PRI-
and potentially the IMMEDIATE precedence levels. The field ORITY and potentially the IMMEDIATE precedence levels. The
grade traffic (brigade, battalion, and division) would use field grade traffic (brigade, battalion, and division) would
the IMMEDIATE, and in some cases FLASH precedence levels. use the IMMEDIATE, and in some cases FLASH precedence levels.
Communications within the Corps and Theater commanders would Communications within the Corps and Theater commanders would
use FLASH. The President, the Joint Chiefs, and some select use FLASH. The President, the Joint Chiefs, and some select
theater commanders (e.g. CICNORAD, or CICSAC) would use the theater commanders (e.g. CICNORAD, or CICSAC) would use the
FLASH OVERRIDE precedence. This guaranteed (in theory) that FLASH OVERRIDE precedence. This guaranteed (in theory) that
the most important commands (the President forbidding nuclear the most important commands (the President forbidding nuclear
launch) would get through even over all other traffic. launch) would get through even over all other traffic.
This pre-grading of importance is a method of assigning maximum This pre-grading of relative importance to a session is how an
levels of priority to traffic based on user Profile (e.g. what authorized user can assign the appropriate priority to traffic
they are authorized to do). Someone who was authorized to use based on that user's Profile (e.g. within what they are auth-
IMMEDIATE precedence would normally use ROUTINE unless there orized to assign a session to). 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 was a legitimate reason to escalate the precedence to a higher
level. level.
4.0 Requisites from ANSI's MLPP Specification [2] 5.0 Requisites from ANSI's MLPP Specification
ANSI T.619-1992 states the 5 levels of Precedence (or ANSI T.619-1992 states the 5 levels of Precedence (or Priority)
Priority) for MLPP networks as the following: for MLPP networks as the following:
bits Name bits Name
---- ---- ---- ----
0000 "Flash Override" (0) 0000 "Flash Override" (0)
0001 "Flash" (1) 0001 "Flash" (1)
0010 "Immediate" (2) 0010 "Immediate" (2)
0011 "Priority" (3) 0011 "Priority" (3)
0100 "Routine" (4) 0100 "Routine" (4)
0101 to 0101 to
1111 "Spare" 1111 "Spare"
There are actually 16 values/levels possible within this spec, There are actually 16 values/levels possible within this spec,
but any additional levels will have a preemption functionality but any additional levels will have a Preemption functionality
below, or less than, "Routine". The intent is that "Flash below, or less than, "Routine". The intent is that "Flash
Override" is always the highest level capable within a MLPP- Override" is always the highest level capable within a MLPP-
compliant network. compliant network.
In any case, a call session of any given Precedence level or In any case, a call session of any given Precedence level or
value can preempt any Precedence level of a lesser level or value can preempt any Precedence level of a lesser level or
value. If these values are equal, then other mechanisms, if value. If these values are equal, then other mechanisms, if
any, can react according to their individual capabilities any, can react according to their individual capabilities
(e.g. Call waiting). (e.g. Call waiting).
skipping to change at page 5, line 50 skipping to change at page 8, line 22
empted by a higher Precedence call shall be required to empted by a higher Precedence call shall be required to
acknowledge the preemption before being connected to acknowledge the preemption before being connected to
the new calling party, and the new calling party, and
c) When there are no idle resources, preemption of the c) When there are no idle resources, preemption of the
lowest of these lower level Precedence resources shall lowest of these lower level Precedence resources shall
occur; occur;
Any call session can be preempted anytime after the Precedence Any call session can be preempted anytime after the Precedence
value has been established for a call and call clearing has value has been established for a call and call clearing has
begun. begun. Here coordination with a Bandwidth aware mechanism such as
RSVP will be needed, making sure that the Preempting call is
assigned that bandwidth freed up from the call clearing action.
If there is a user or SIP device that is configured (somehow If there is a user or SIP device that is configured (somehow
compliant with the parameters within that Administrative Domain compliant with the parameters within that Administrative Domain
(AD), and outside the scope of this document) to disable the (AD), and outside the scope of this document) to disable the
ability to be preempted, that user or SIP phone device will ability to be preempted, that user or SIP phone device will
not experience preemption of calls by higher precedence calls, not experience preemption of calls by higher precedence calls,
if the cause of preemption would be due to called party busy if the cause of preemption would be due to called party busy
condition (e.g. call waiting is enacted here). However, the condition (e.g. call waiting is enacted here). However, the
user may still experience preemption of calls due to a lack user may still experience preemption of calls due to a lack
of network resources other than the user's own access resources of network resources other than the user's own access resources
[2]. [2].
Precedence calls that are not responded to by the called party Precedence calls that are not responded to by the called party
(e.g. the called party chooses to hang up their phone without (e.g. the called party chooses to hang up their phone without
taking the call) may have their phone speaker initialized for taking the call) may have their phone speaker initialized for
that inbound Precedence call in order to complete the call; that inbound Precedence call in order to complete the call;
sometimes regardless if this called party wants the Precedence sometimes regardless if this called party wants the Precedence
call [2]. An alternative to this approach could be to have an call [2]. Section 8.0 of this I-D discusses the potential rele-
'alternate called party' signaled (e.g. that person's admini- vance of this feature. An alternative to this approach could
strator). This mechanism would be a per Domain decision, and be to have an 'alternate called party' signaled (e.g. that
not mandatory for SIP-MLPP interworking compliance. person's administrator). 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 An MLPP call session should automatically be set up with the
lowest precedence level by default, until the user chooses a lowest precedence level by default until the user chooses a
level up to their maximum allowed within that Domain. level up to 'their' maximum authorized within that Domain.
Controlling whether users always chose the lowest level, or the
Appropriate level, is an administrative decision, and outside of
the scope of this document.
5.0 Defined SIP Priority request-header field 6.0 Defined SIP Priority request-header field
SIP[1] defines the Priority request-header field and its SIP [1] defines the Priority request-header field and its
possible non-mandatory values in section "6.25 Priority" as possible non-mandatory values in section "6.25 Priority" as
the following (exact text from page 40 of [1]): the following (exact text from page 40 of [1]):
" Priority = "Priority" ":" priority-value " Priority = "Priority" ":" priority-value
priority-value = "emergency" | "urgent" | "normal" priority-value = "emergency" | "urgent" | "normal"
| "non-urgent" | "non-urgent"
It is RECOMMENDED that the value of "emergency" only be It is RECOMMENDED that the value of "emergency" only be
used when life, limb or property are in imminent danger. used when life, limb or property are in imminent danger.
Examples: Examples:
Subject: A tornado is heading our way! Subject: A tornado is heading our way!
Priority: emergency Priority: emergency
Subject: Weekend plans Subject: Weekend plans
Priority: non-urgent Priority: non-urgent
These are the values of [3], with the addition of These are the values of [8], with the addition of
"emergency". " "emergency". "
This author sees no inconsistencies in adding the "Flash In the 2543bis draft [7], this has changed to include a 5th
Override" Value with [1]. Priority value "other priority" (section 6.31 of [7]), but
doesn't change the semantics of this section otherwise; meaning
"emergency" is still the recommendation for highest Priority,
but only in the case of an *emergency* (pun partially intended).
The next level with less Priority is "urgent", which is followed
by the Priority value that might as well be the default Priority
value of most SIP messages, because this is the value for "normal"
traffic - where most voice sessions will take place. Whatever the
"non-urgent" value is supposed to provide other than less than
"normal", it doesn't match the MLPP model at this end of the
spectrum as well as not having multiple "emergency" levels similar
to MLPP ("Flash" and "Flash Override").
6.0 Merging Priority Value Sets Even if "non-urgent" were mapped to everyday session traffic,
the Priority model of [3&7] won't match enough, and a separate
Header-Field is necessary
When comparing sections 4.0 and 5.0, the only difference in Both [3 & 7] state this Header-Field is not necessary, it fact it
the values is this fifth value in MLPP, the Highest Priority Has been mentioned at numerous meetings that this header-Field
value ("Flash Override"), although each has a subtly different isn't even used, so why all the fuss about MLPP.
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 7.0 Request Header-Field:MLPP-Enabled Extension
The MLPP-Enabled request-header field indicates the relative Pri-
ority of the session initiation as perceived by the client.
MLPP-Enabled = "MLPP-Enabled" ":" MLPP-priority-value
MLPP-priority-value = "Flash Override" | "Flash"
| "immediate" | "Priority" | "Routine"
The semantics are a repeat of the Military example from section
3.0:
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 PRI-
ORITY 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 relative importance to a session is how an
authorized user can assign the appropriate priority to traffic
based on that user's Profile (e.g. within what they are auth-
orized to assign a session to). 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.
7.1 A subset of MLPP?
A subset of MLPP can also be implemented not having all 5 levels
of Precedence, and still be quite useful in infrastructures
desiring the explicit benefits of the semantics stated above, yet
don't implement all 5 levels from a case of need.
Examples can easily be seen in Hospitals under emergency situa-
tions like power outages or "Code Blues" where a patient's heart
has stopped and the IP infrastructure requires an explicit mecha-
nism in place to ensure Prioritized traffic reaches its destina-
tions in the time expected.
Another example is where this relative Prioritization of certain
types of traffic (here SIP initiated) are constantly provided
the higher levels regardless of the state of the network con-
gestion levels at any time. Financial Institutions where stock
trading occurs and can't "get a busy signal".
8.0 Results of MLPP-Enabled Extension to SIP
The following are recommendations or requirements for a SIP The following are recommendations or requirements for a SIP
Signaling Environment or Domain enabled with MLPP, or a Signaling Environment or Domain enabled with MLPP, or a
subset of MLPP, for the purposes of creating a Network where subset of MLPP, for the purposes of creating a Network where
Voice Sessions have a need for sub-classification within a Voice Sessions (at first) have the need for Precedence
Domain's control: classification within a Domain's control.
* SIP end-device MUST include the Header-Field "Priority:" This is the purpose of this request for Extension to the SIP
in all Session Signaling, regardless of session's intent Protocol, and the reason I believe this should be a separate
or destination; effort, not tied to the main SIP effort. I realize this isn't to
be implemented everywhere (too tight or focused a specification)
and desire the vendors and customers to look at this specifi-
cation separately for implementation purposed both in products to
be built, and features to be incorporated:
* Header-Field "Priority:" MUST be default set to 'Routine' * SIP end-device MUST include the Request Header-Field
unless calling user specifies a Domain authorized Higher "MLPP-Enabled:" in all session signaling, regardless of
Value for that call session; the session's intent or destination;
* User must be authorized to access higher priority values * Header-Field " MLPP-Enabled:" MUST be default set to
for any Higher Precedence call (method of authorization 'Routine' unless the calling party specifies an author-
is outside the scope of this document); ized Higher Value for all call sessions;
* User must be authorized to access higher Priority values
for any Higher Precedence session initiations (method of
authorization is outside the scope of this document) in
order to utilize those higher levels;
* MUST allow Administrator to make it mandatory for any SIP * MUST allow Administrator to make it mandatory for any SIP
receiving device to be MLPP-enabled (goal to have any receiving device to be MLPP-enabled (goal to have any
non-MLPP device not able to engage in any call session - non-MLPP device not able to engage in any call session -
in a MLPP environment, this capability should be required in a MLPP environment, this capability should be required
of all devices by that Domain's Administrator) of all devices by that Domain's Administrator)
* Otherwise call isn't established with the following op- * Otherwise call isn't established with the following op-
tional (rough language) results: tional (rough language) results:
* Automated attendant stating to caller "remote device * Automated attendant stating to caller "remote device
not MLPP-enabled... call cannot be completed" - call not MLPP-enabled... call cannot be completed" - call
gets either fast-busy or new tone indicating bad gets either fast-busy or new tone indicating bad
remote device called; remote device called;
* Automated attendant stating caller "remote device not * Automated attendant stating caller "remote device not
MLPP-enabled... do you wish to proceed with non-pri- MLPP-enabled... do you wish to proceed with non-pri-
oritized call anyway" oritized call anyway"
* Simply fast busy * Simply a fast busy
* SIP Gateways within MLPP-enabled Domain MUST have direct * SIP-based Gateways within MLPP-enabled Domain MUST have
mapping of ISDN Signaling according to [2 and 5]; direct mapping of ISDN Signaling according to [2 and 9],
else they should merely create the SIP Header with the
request Header-Field MLPP-Enabled, while entering a Pre-
dence value of "Routine" for that session;
* It is believed COPS should be utilized for mid-session * It is believed COPS should be utilized for mid-session
path rejections due to congestion, when a Higher Prece- path rejections due to congestion (of what [2] calls
dence Call session is requesting resources, but that "call clearing", when a Higher Precedence Call session
mechanism is currently outside of the scope of this is requesting resources, but that mechanism is currently
document, but might be more detailed in a future version outside of the scope of this document, but might be more
of this I-D; detailed in a future version of this I-D;
8.0 IANA Considerations 9.0 Unknowns needing discussion still
There are many unknowns still regarding the migration of the
original ANSI requirements in [2] into a SIP implementation here.
Discussion would be greatly encouraged on at least these issues
listed below to determine from the original requirements for
having something like MLPP, how much of those requirements need
to evolve for today's (and the future's) capabilities in
networking. Here is a brief list of a few of them:
o Conferencing - if a caller is on the conference bridge,
for example, and a call clear event occurs
(meaning they are the recipient of the
inbound higher priority call) does every-
one need to hear the audible tone?
If a caller is on a conference bridge, and
they are preempted by a network resource
bottleneck that causes their respective
leg to terminate, does everyone hear the
audible tone
Should there be some provision for
announcing to the conference 'who' has
been terminated from the call (where
possible by some other mechanism)?
o Version ID - Currently [7] defines as mandatory the
SIP version number or value be included
(section 4.3.1 of [7] to be specific). I
don't know yet how to identify this cap-
ability of MLPP in the SIP headers. I
don't know in a 'letter' should be added
to the SIP/2.0? I'm at a loss right now on
how to solve this and am looking for
suggestions.
o Speaker - The part of the ANSI spec [2] which states
that if the called party who is still in a
session has to acknowledge the higher pri-
ority in-bound session and answer it, else
have their respective device's speaker
turned on (in the case of that user merely
hanging up or terminating the session to
avoid answering or acknowledgement of this
new session). This feature might not be
desired further, but there should dis-
cussion from those that have experience
with MLPP to see if this is the case.
9.0 Changes since the Last Version
The following is a list of the noticeable changes to this effort
from the -00 version of this I-D:
o Changed the name and scope of this draft to "SIP Extension
for MLPP" requesting that a separate Request Header-Field:
MLPP-Enabled be created in this draft on a Standards Track
apart from the main SIP effort due it limited focus, yet
usefulness within certain markets
o Hinted at the potential synergies with both IEPS and GETS
efforts
o Suggested the use of a sub-set of the MLPP effort outside the
strict environments that still require all of MLPP's features
like Hospitals and Financial Institutions
o Added section 9.0 "Unknowns" to this version to attempt to
bring out the known differences in the why in which Voice
networks operated 'then' verses now and in the near future;
10.0 IANA Considerations
This author doesn't believe there are any within this document. This author doesn't believe there are any within this document.
9.0 Security Considerations 11.0 Security Considerations
It can be argued that Authentication and Authorization of Call It can be argued that Authentication and Authorization of Call
Sessions will not require any security mechanisms until Pri- Sessions will not require any security mechanisms until Pri-
ority, Precedence and Preemption are enabled within a network ority, Precedence and Preemption are enabled within a network
Domain. Once any or each of these are implemented within a Domain. Once any or each of these are implemented within a
Domain Network, Security considerations could become signifi- Domain Network, Security considerations could become signifi-
cantly more important to that Domain. cantly more important to that Domain.
In an MLPP-enabled Domain, unauthorized setting of any Higher In an MLPP-enabled Domain, unauthorized setting of any Higher
Priority session should have a great impact on other traffic Priority session should have a great impact on other traffic
unless there is no congestion occurring at any point within the unless there is no congestion occurring at any point within the
network, at any time. This author believes Security and Encryp- network, at any time. This author believes Security and Encryp-
tion will become very important within Packetized Voice Communi- tion will become very important within Packetized Voice Communi-
cations in the near future. cations in the near future.
Since [2] mandates that each MLPP be defined and (relatively) Since [2] mandates that each MLPP be defined and (relatively)
closed in nature, boundary controls can and should be possible. closed in nature, boundary controls can and should be possible.
10.0 References: 12.0 References:
[1] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "SIP: [1] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "SIP:
Session Initiation Protocol" RFC 2543, March 1999 Session Initiation Protocol" RFC 2543, March 1999
[2] ANSI specification ANSI T1.619-1992. [2] ANSI specification ANSI T1.619-1992.
[3] Palme, J., "Common Internet message headers", RFC 2076, [3] J. Rosenberg, H. Schulzrinne "draft-ietf-sip-guidelines-01"
February 1997. IETF Internet Draft, November 2001
[4] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and [4] K. Carlberg, "draft-carlberg-ieps-framework-00", Internet
Draft, November 2000
[5] James M. Polk, IETF Internet Draft "draft-polk-mlpp-over-ip",
March 2001
[6] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. (section Functional Specification", RFC 2205, September 1997. (section
3.5 and Appendix B) 3.5 and Appendix B)
[5] ANSI specification ANSI T1.619A-1994. [7] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg
"draft-ietf-sip-rfc2543bis-02" IETF Internet Draft, November 24,
2000
[6] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding [8] Palme, J., "Common Internet message headers", RFC 2076,
PHB" RFC 2598, June 1999 February 1997.
[9] ANSI specification ANSI T1.619A-1994.
11.0 Acknowledgments 11.0 Acknowledgments
A couple of people have made comments and suggestions contribu- I'd like to thank Scott Bradner for his advice on this effort
ting to this document. In particular, this author would like and all of this MLPP efforts direction within the IETF up to
to thank Bob Bell and Rohan Mahy of Cisco Systems. this point.
12.0 Author Information 12.0 Author Information
James M. Polk James M. Polk
Cisco Systems Cisco Systems
18581 N. Dallas Parkway, Suite 100 18581 N. Dallas Parkway, Suite 100
Dallas, TX 75287 Dallas, TX 75287
jmpolk@cisco.com jmpolk@cisco.com
"Copyright (C) The Internet Society (date). All Rights "Copyright (C) The Internet Society (date). All Rights
skipping to change at page 10, line 25 skipping to change at page 16, line 43
This document and the information contained herein is provided This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE." PARTICULAR PURPOSE."
The Expiration date for this Internet Draft is: The Expiration date for this Internet Draft is:
September 8, 2000 September 2, 2001
 End of changes. 43 change blocks. 
129 lines changed or deleted 381 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/