< draft-polk-sipping-mlpp-reqs-00.txt   draft-polk-sipping-mlpp-reqs-01.txt >
Internet Engineering Task Force James M. Polk Internet Engineering Task Force James M. Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration: Aug 24th, 2003 Expiration: Dec 30th, 2003
File: draft-polk-sipping-mlpp-reqs-00.txt File: draft-polk-sipping-mlpp-reqs-01.txt
Multilevel Precedence and Preemption Multilevel Precedence and Preemption
in the Session Initiation Protocol in the Session Initiation Protocol
February 24th, 2003 June 30th, 2003
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and Internet-Drafts are draft documents valid for a maximum of six
may be updated, replaced, or obsoleted by other documents at any time. It months and may be updated, replaced, or obsoleted by other documents
is inappropriate to use Internet-Drafts as reference material or to cite at any time. It is inappropriate to use Internet-Drafts as reference
them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html. at http://www.ietf.org/shadow.html.
Abstract Abstract
This document proposes considerations and requirements for the extension This document proposes considerations and requirements for the
of the Session Initiation Protocol (SIP) [1] to support an IP version of extension of the Session Initiation Protocol (SIP) [1] to support
Multi-Level Precedence and Preemption functionality originally set forth Multi-Level Precedence and Preemption (MLPP) functionality
in [2&3]. This document will be limited in scope to aspects having to do originally set forth in [2&3]. This document will be limited in
with the SIP Protocol. MLPP within the IETF utilizing other IETF Protocols scope to the requirements of the SIP Protocol; MLPP within the IETF,
is left to other documents, therefore is considered out of scope here. utilizing other IETF Protocols, is left to other documents,
therefore is considered out of scope here - although there is a
general explanation of how MLPP functions currently within private
circuit switched networks to give the necessary operational
background for these requirements.
Polk Page [1]
Table of Contents Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Conventions used in this document . . . . . . . . . . . 3
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4
1.1 Conventions used in this document . . . . . . . . . . . . . . . 3 3. MLPP Operational Functionality . . . . . . . . . . . . . . . 5
2.0 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . 4 3.1 MLPP Precedence . . . . . . . . . . . . . . . . . . . . 6
3.0 MLPP Operational Functionality . . . . . . . . . . . . . . . . . 6 3.2 Operational Behavior for Preemption . . . . . . . . . . 7
3.1 MLPP Precedence . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1 Modes of Preemption in CSN Systems . . . . . . . . . . 7
3.2 Operational Behavior for Preemption . . . . . . . . . . . . . . 7 3.3 Access Preemption Event . . . . . . . . . . . . . . . . 8
3.2.1 Modes of Preemption in CSN Systems . . . . . . . . . . . . . . . 7 3.4 Network Preemption Event . . . . . . . . . . . . . . . 10
3.3 Access Preemption Event . . . . . . . . . . . . . . . . . . . . 9 4. MLPP/IP Basic Model . . . . . . . . . . . . . . . . . . . . . 11
3.4 Network Preemption Event . . . . . . . . . . . . . . . . . . . . 10 4.1 Components of the Basic Model . . . . . . . . . . . . . 11
4.0 MLPP over IP Basic Model . . . . . . . . . . . . . . . . . . . . 11 5. SIP Multilevel Precedence and Preemption Requirements . . . . 12
4.1 Components of the Basic Model . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
5.0 SIP Multilevel Precedence and Preemption Requirements . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7.0 Security Considerations . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Author Information . . . . . . . . . . . . . . . . . . . . . 16
10.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
11.0 Author Information . . . . . . . . . . . . . . . . . . . . . . . 16
1.0 Introduction 1.0 Introduction
This document proposes considerations and requirements for the extension This document proposes considerations and requirements for the
of the Session Initiation Protocol (SIP) [1]to support an IP version of extension of the Session Initiation Protocol (SIP) [1] to support an
Multi-Level Precedence and Preemption functionality originally set forth IP version of Multi-Level Precedence and Preemption (MLPP)
in [2&3]. This document will be limited in scope to aspects having to do functionality originally set forth in [2&3]. This document will be
with the SIP Protocol. MLPP within the IETF utilizing other IETF Protocols limited in scope to aspects having to do with the SIP Protocol. MLPP
is left to other documents, therefore is considered out of scope here. within the IETF utilizing other IETF Protocols is left to other
documents, therefore is considered out of scope here.
MLPP was originally written to create ôa prioritized call handling MLPP was originally written to create "a prioritized call handling
serviceö in combination with ISDN supplementary services. MLPP has two service" in combination with ISDN supplementary services. MLPP has
very simple concepts for voice and video (Real-Time) communications: two very simple concepts for voice and video (Real-Time)
communications:
A) labeling or marking every call (at inception) with a Precedence A) labeling or marking every call (at inception) with a
level relative to other calls within a single administrative Precedence level relative to other calls within a single
domain, or federation of domains; and administrative domain, or federation of domains; and
B) during times of congestion at any point in the network, the B) during times of congestion at any point in the network, the
point of congestion at the endpoint or internetworking device, device experiencing congestion will determine if preempting
having that device determine if preempting (seizing) the (seizing) the resources of any identifiable lower relative
resources of any identifiable lower relative priority call(s) is priority call(s) is required to properly set-up a newly
required to properly set-up a newly signaled higher priority signaled higher priority call
call
This administrative control and network functionality exists today in Polk Page [2]
several large deployments. It is based, or founded, in US Government This administrative control and network functionality exists today
network requirements. [2,3] is an augmentation service to ANSIÆs ISDN in several large deployments. It is based, or founded, in US
[8,9,10,11]. Several other non-US networks have been enabled with this Government network requirements. MLPP [2, 3] is a supplementary
MLPP functionality in the past decade. Most of these networks are looking service to ISDN [8, 9, 10]. Several other non-US networks have been
to incorporate IP signaling and transport of their voice and video enabled with this MLPP functionality in the past decade. Most of
services and require the MLPP functionality during the transition and these networks are looking to incorporate IP signaling and transport
progression/evolution of their networks in times of government or military of their voice and video services and require the MLPP functionality
emergencies when congestion causes critical systems communications to during the transition and progression/evolution of their networks in
falter. times of government or military emergencies when congestion causes
critical systems communications to falter.
The applications currently run by these networks are voice and video The applications currently run by these networks are voice and video
services only. In the future, Instant Messaging and email are targets for services only. In the future, Instant Messaging and email are
this capability as well, but will not be further discussed within this targets for this capability as well, but will not be further
document. discussed within this document.
This document will focus on the considerations and requirements on SIP This document will focus on the considerations and requirements on
Proxies, Gateways and User Agents, concentrating on what needs to be SIP Proxies, Gateways and User Agents, concentrating on what needs
addressed to enable MLPP functionality. to be addressed to enable MLPP functionality.
Considerations need to be met and realized in the user experience of the Considerations need to be met and realized in the user experience of
existing MLPP service. Because of the existing size of these networks (one the existing MLPP service. Because of the existing size of these
network has several million end-stations), the migration of their networks (one network has several million end-stations), the
communications over to an IP based system cannot occur quickly. With this migration of their communications over to an IP based system cannot
in mind, many considerations should be kept in mind that this is not a occur quickly. With this in mind, many considerations should be kept
brand new installation. Further, all new implementations with this in mind that this is not a brand new installation. Further, all new
functionality with IP endpoints will be primary line endpoints, and not in implementations of IP endpoints with MLPP functionality will be
secondary configurations. replacing the old infrastructure (and endpoints).
Most of the requirements here have been taken from [2&3]. Any remaining Most of the requirements here have been taken from [2&3]. Any
details and concepts attained from documents came from the certification remaining details and concepts attained from documents came from the
materials which all products must be tested against to achieve MLPP certification materials which all products must be tested against to
compliance and interoperability status in [4&5]. There are a few concepts achieve MLPP compliance and interoperability status in [4&5]. There
mentioned here that were attained from interviewing users and testers of are a few concepts mentioned here that were attained from
MLPP for guidance of how this MLPP-concept might be enhanced with the interviewing users and testers of MLPP for guidance of how this
additional capabilities that IP and IP-based services brings to offer. MLPP-concept might be enhanced with the additional capabilities that
IP and IP-based services brings to offer.
This document will cover new terminology used within MLPP infrastructures. This document will cover new terminology used within MLPP
Also included will be an overview of the current decision process that infrastructures. Also included will be an overview of the current
exists within the MLPP enabled network. This will be followed by the decision process that exists within the MLPP enabled network. This
SIP(PING) requirements for enabling this functionality in this working will be followed by the SIP(PING) requirements for enabling this
group. functionality in this working group.
1.1 Conventions used in this document 1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [6]. this document are to be interpreted as described in [6].
Polk Page [3]
2.0 Terms and Definitions 2.0 Terms and Definitions
The following is a list of definitions and conventions to used throughout The following is a list of definitions and conventions to used
this document. Note that some of the definitions are either MLPP *or* IP throughout this document. Note that some of the definitions are
centric, and might not make sense to the other. Advice is taking these either MLPP *or* IP centric, and might not make sense to the other.
words in the context of the section of this document they are written in. Advice is taking these words in the context of the section of this
document they are written in.
Alternate Party Is another endstation which is configured for any Alternate Party is the party to which a precedence call will be
call diversion if the Called device has an inbound diverted. Diversion will occur either when the
Precedence inbound call while that Called User is response timer T-sub-k expires, when the called
actively on a call/session party is busy on a call of equal or higher
precedence, or when the called party is busy with
access resources non-preemptable. Alternate party
diversion is an optional terminating feature that
is subscribed to by the called party; thus, the
alternate party to which a precedence call is
diverted is specified by the called party at the
time of subscription
CSN Circuit Switched Network - public or private TDM CSN Circuit Switched Network - Public or private
Infrastructure; most often this will refer to the infrastructure using circuit-switched technology,
existing MLPP enabled closed network of within the such as provided by TDM transmission facilities,
same domain, and not the publicly available dial rather than packet technologies; most often this
circuits will refer to the existing MLPP enabled closed
network or within the same domain, and not the
publicly available dial circuits
Domain A network under one single administrative control Domain A network under one single administrative control
entity, possibly non-adjacent geographically, meaning entity
network islands interconnected by an intermediary
(Service) Provider
End Office Node EN û see EOS
End Office Switch EOS û An MLPP capable PBX configured to only service
that local community and its needs; it is internal
network controlled; this unit connects all CPE
equipment in that community
Gateway Converts media provided in one type of network to the End Office Node EN - see EOS
format required in another type of network; the
gateway shall be capable of full duplex audio trans-
lations
GSTN Global or General Switched Telephone Network û world- End Office Switch EOS - An MLPP capable circuit switching system
wide circuit-switched public telephony network configured to interconnect user lines and trunks
ISDN Integrated Services Digital Network ISDN Integrated Services Digital Network
Look ahead For Busy LFB û a feature of MLPP in which a phone can look Look ahead For Busy LFB - a feature of MLPP in which a phone can look
ahead in the network to determine if a call it is ahead in the network to determine if a call it is
about to place has available resources for call about to place has available resources for call
completion completion
MLPP Multi-level Precedence and Preemption [2&3] û ANSI MLPP Multi-level Precedence and Preemption [2&3] - ANSI
T1.619 and 619A specifications stipulating mechanisms T1.619 and 619A Standards stipulating mechanisms
for marking each voice communication with a for marking each voice communication with a
Precedence level, and defining the requirement for Precedence level, and defining the requirement for
the Preemption of existing lower Precedence sessions the Preemption of existing lower Precedence
during congestion in favor of new higher Precedence sessions during congestion in favor of new higher
session(s) Precedence session(s)
MLPPoIP MLPP (functionality) over (an) IP network(s)
Multifunction Switch MFS - A combination of a End Office Switch (EOS) and Polk Page [4]
Tandem Switch (TS); having trunking and CPE Multifunction Switch MFS - A combination of a End Office Switch (EOS)
connection capabilities within one, more economical and Tandem Switch (TS); having trunking and CPE
unit connection capabilities within one, more
economical unit
Precedence The relative priority level assigned to each call by Precedence The relative priority level assigned to each call
the caller at inception by the caller at inception
Precedence Call Any call that has a Precedence level higher than Precedence Call Any call that has a Precedence level higher than
Routine Routine
Preempt Notification The audible notification sent to all endstations who Preempt Notification The audible notification sent to all endstations
have been preempted for any reason who have been preempted for any reason
Preempted Any caller who has had their existing call cleared Preempted Any caller who has had their existing call cleared
Or disconnected Or disconnected
Preempting Call A call with a Precedence level higher than others Preempting Call A call with a Precedence level higher than others
on a specified interface at a time of congestion, on a specified interface at a time of congestion
including an end-station that is on a call
Proxy Server SIP Server [1] that acts on behalf of other devices
Registrar Server SIP Server [1] that serves as a Registration point Registrar Server SIP Server [1] that serves as a Registration point
principally for mobility principally for mobility
Response Timer T-sub-K Is started when the network notifies the Called Response Timer T-sub-K Is started when the network notifies the Called
device of a inbound precedence call; acceptance must device of a inbound precedence call; acceptance
occur by the Called device; the timer is specified in must occur by the Called device; the timer is
[2] at from 4 û 30 seconds specified in [2] at from 4-30 seconds
Response Timer T-sub-L Is started when an LFB information unit is sent Response Timer T-sub-L Is started when an LFB information unit is sent
into the network to establish an open path between into the network to establish an open path between
the Calling endstation and the intended called end- the Calling endstation and the intended called
station; the timer is expected in [2] as from 5 û 20 endstation; the timer is expected in [2] as from
seconds 5û20 seconds
SLA Service Level Agreement û Agreement between two
adjacent networks on many aspects of how oneÆs
traffic gets treated within the otherÆs network
Tandem Switch TS - Only connects to EOSÆs; is the primary backbone
of a circuit-switched MLPP Network
User Agent UA defined in [1] as an application which can act
both as a user agent client and user agent server
User Agent Client UAC defined in [1] as a client application that
initiates a SIP request
User Agent Server UAS defined in [1] as a server application that Tandem Switch TS - Only connects to EOS's and other TS's; is the
replies to SIP requests. The response accepts, primary backbone of a circuit-switched MLPP
rejects or redirects the request. Network
3.0 MLPP Operational Functionality 3.0 MLPP Operational Functionality
This section will provide the operational functionality of an MLPP This section will provide the operational functionality of an MLPP
infrastructure. The requirements section later in this document will be infrastructure. The requirements section later in this document will
based on this section (and subsections) for its operational requirements be based on this section (and subsections) for its operational
in SIP(PING). requirements in SIP(PING).
The following from the core MLPP documents [2,3] must be referenced in The following subsections are from the core MLPP documents [2,3], as
detail, as well as the documents involving the actual testing of any well as the documents involving the actual testing of any component
component for certification of MLPP compliance [4,5,7]. for certification of MLPP compliance [4,5,7].
The root specification [2] states that there are two conceptual parts to Polk Page [5]
MLPP: Precedence and Preemption. The root specification [2] states that there are two conceptual
parts to MLPP: Precedence and Preemption.
3.1 MLPP Precedence 3.1 MLPP Precedence
Precedence means Priority. It is the relative priority of a call to all Precedence means Priority. It is the relative priority of a call to
other calls within that domain (or federation of domains if applicable) all other calls within that domain (or federation of domains if
when traversing any interface, including an endstation. It is set or applicable) when traversing any interface, including an endstation.
assigned by the calling party at the beginning of a call, on a per call It is set or assigned by the calling party at the beginning of a
basis. Once the precedence level is chosen by a caller, it cannot be call, on a per call basis. Once the precedence level is chosen by a
changed for the duration of that call. The next call being independent of caller, it cannot be changed for the duration of that call. The next
the first call, can be made at another authorized level, also chosen by call being independent of the first call, can be made at another
the calling party. authorized level, also chosen by the calling party.
The table below from [2] specifies the precedence values as: The table below from [2] specifies the precedence values as:
Priority ISDN Text Priority ISDN Text
Level Sequence Sequence Level Sequence Sequence
--- ---- -------- --- ---- --------
1 "0000" = "Flash Override" (highest level) 1 "0000" = "Flash Override" (highest level)
2 "0001" = "Flash" 2 "0001" = "Flash"
3 "0010" = "Immediate" 3 "0010" = "Immediate"
4 "0011" = "Priority" 4 "0011" = "Priority"
5 "0100" = "Routine" (lowest level) 5 "0100" = "Routine" (lowest level)
"0101 û 1111" are unspecified "0101 - 1111" are unspecified
The possible levels the call can be assigned, in CSN MLPP infrastructures, The possible levels the call can be assigned, in CSN MLPP
is bound to the allowable levels set on the switch (or EOS) for that infrastructures, are bound to the allowable levels set on the switch
circuit. Each line in this infrastructure is configured to only allow (EOS) for that line. Each line in this infrastructure is configured
certain levels to be chosen by anyone accessing that phone. Someone with to only allow certain levels to be chosen by anyone accessing that
personal access to higher levels than that of the phone they're in front phone. Someone with personal access to higher levels than that of
of, needs to go to a phone with access to those higher precedence levels the phone they're in front of, needs to go to a phone with access to
in order to make a higher precedence call. those higher precedence levels in order to make a higher precedence
call. Conversely, a person with lower allowable privileges can
access higher precedence levels by placing calls from a phone that
has those levels authorized on that line.
Because the precedence level chosen for a (or any) call is used solely in Because the precedence level chosen for a (or any) call is used
the determination of which call or calls are preempted (should congestion solely in the determination of which call or calls are preempted
occur at any point or interface this call traverses) as explained in the (should congestion occur at any point or interface this call
next section, the user of that phone cannot use a level above what they traverses) as explained in the next section, the user of that phone
are authorized to gain access to. cannot use a level above what they are authorized to gain access to.
Since UAs aren't bound by any physical connection to a switch, this Since UAs aren't bound by any physical connection to a switch, this
restraint no longer will exist. Thus, another means will be required by restraint no longer will exist. Thus, another means will be required
SIP to restrict the unauthorized use of higher precedence calls by those by SIP to restrict the unauthorized use of higher precedence calls
that are not allowed to signal these precedence values in their INVITE by those that are not allowed to signal these precedence values in
messages. their INVITE messages.
An important background note, the determination of who is granted An important background note, the determination of who is granted
permission to make precedence calls (meaning any call with a precedence
level higher than routine - the lowest level) is by job function in most Polk Page [6]
MLPP networks, and not by who they are, or how long they've been with that permission to make precedence calls (meaning any call with a
organization. This is the case within the US "DSN" network. This means precedence level higher than routine - the lowest level) is by job
that if there is a job related rank to each person's employment, higher function in most MLPP networks, and not by who they are, or how long
ranking employees don't necessarily dictate access to higher precedence they've been with that organization. This is the case within the US
call privileges, but in practice, this is generally close to alignment. "DSN" network. This means that if there is a job related rank to
each person's employment, higher ranking employees don't necessarily
dictate access to higher precedence call privileges, but in
practice, this is generally close to alignment.
3.2 Operational Behavior for Preemption 3.2 Operational Behavior for Preemption
Preemption (in a CSN case) is the seizing of otherwise used resources of Preemption (in a CSN case) is the seizing of otherwise used
one or more calls in order to complete another call in a congestion resources of one or more calls in order to complete another call in
situation. The nodes that determine preemption are EOSs or TNs in the CSN a congestion situation. The nodes that determine preemption are EOSs
infrastructure. The decision is based on the precedence values assigned to or TNs in the CSN infrastructure. The decision is based on the
each circuit with the trunk groups on those nodes. When a call is placed, precedence values assigned to each circuit with the trunk groups on
the transiting node maintains state as to the precedence value of that those nodes. When a call is placed, the transiting node maintains
call assigned to a inbound and outbound port on that node. state as to the precedence value of each call assigned to a inbound
and outbound port on that node.
When a new call is signaled (via SS7) into that CSN node, the node looks When a new call is signaled (via SS7) into that CSN node, the node
for available resources to route that call through. If the node determines looks for available resources to route that call through. If the
that it has no more outbound (egress) resources available (for example on node determines that it has no more outbound (egress) resources
a T1 interface) for this new call, a comparison is performed of this new available (for example on a T1 interface) for this new call, a
call's precedence value to that of all the other calls existing on that comparison is performed of this new call's precedence value to that
outbound interface. If this new call has a higher precedence value than of all the other calls existing on that outbound interface. If this
any one of the other calls, one or more calls (in fact all that are new call has a higher precedence value than any one of the other
necessary) are cleared to complete this new call. calls, one or more calls (in fact all that are necessary) are
cleared to complete this new call.
3.2.1 Modes of Preemption in CSN Systems 3.2.1 Modes of Preemption in CSN Systems
There are two modes of Preemption: preemption of the called device with There are two modes of Preemption: preemption of the called device
another inbound higher precedence call (Access Preemption Event), and with another inbound higher precedence call (Access Preemption
preemption within the network not involving either party of the preempted Event), and preemption at any point of congestion between non-
call at all, but at a point of congestion (Network Preemption Event) endpoint nodes within the network (Network Preemption Event).
between CSN nodes.
MLPP is mandated in [2] as having call handling influence with a single
domain based implementation only. The precedence value set in one MLPP
Domain SHOULD NOT cross domain boundaries into another domain and have any
preferential treatment applied to that call. The MLPP Domain-Identifier
[2] was included in the ISDN and SS7 for this reason. MLPP compliant
Tandems (TNÆs) are to look at the Precedence level set within the call
set-up signaling as well as the domain identifier within that same call
set-up to ensure validity within that network. This prevented leaking of
one domainÆs call behavior into anotherÆs. In other words, no preemption
of any resources shall occur within a domain as a result of a call into
that domain from outside the domain, even if both domains are MLPP
compliant networks.
Here are the three preemption conditions:
o A distinctive preemption notification (tone) shall be introduced
into any connection(s) that is to be cleared due to either a Access
or network Preemption event; (this is not a SIP protocol issue, but
an implementation one, yet worth noting here)
o The party on the inbound end of a preempting call MUST acknowledge MLPP is mandated in [2] as having call handling influence within a
that inbound call before connection to that call; single domain based implementation only. The precedence value set in
one MLPP Domain SHOULD NOT cross domain boundaries into another
domain and have any preferential treatment applied to that call. In
other words, no preemption of any resources shall occur within a
domain as a result of a call into that domain from outside the
domain, even if both domains are MLPP compliant networks. The MLPP
Domain-Identifier [2] was included in the ISDN and SS7 in order to
provide for a final check that the domains match before applying
preemption.
o Upon determination of no available resources and calls existing on Polk Page [7]
an interface of lower precedence, the lowest level call(s) MUST be Here are the three preemption conditions:
cleared in order to complete the higher precedence call;
A call can be preempted at any time after the precedence level has been a) A distinctive preemption notification (tone) shall be introduced
determined to be lower than the existing call and before call clearing has into any connection(s) that is to be cleared due to either a
begun. However, no preemption of any resources shall occur within a domain Access or network Preemption event; (this is not a SIP protocol
as a result of a call into that domain from another domain, even if both issue, but an implementation one, yet worth noting here)
domains are MLPP compliant networks.
A clarification must be stated: higher precedence provides preferential b) The called party MUST acknowledge an inbound precedence call
call handling throughout an MLPP domain, regardless of how much higher a before connection to that call;
call is relative to others. For example, a "Routine" call is equally lower
in precedence level than "Priority", "Immediate", "Flash" and "Flash
Override" as far as preferential treatment in the network is concern.
Having stated that, currently there is no recognized/Standardized method c) Upon determination of no available resources and calls existing
or mechanism in the case of which one of several lower precedence calls on an interface of lower precedence, the lowest level call(s)
gets disconnected, where such a condition exists. Only such that the MUST be cleared in order to complete the higher precedence call;
lowest level call are the first to get disconnected. But if there are more
than one such lower level call existing at a congested interface and a
higher precedence call comes through, determining which lowest level call
gets preempted first is left to the implementer.
An example, if there is a saturated interface with 6 equal bandwidth A call can be preempted at any time after the precedence level has
connections existing, 1 "Flash" call, 1 "Immediate" and 4 "Routine" calls, been determined to be lower than the new call and before call
when another "Flash" level attempts to gain resources out that interface; clearing has begun. However, no preemption of any resources shall
if that new "Flash" call is the same bandwidth as the others (all are occur within a domain as a result of a call into that domain from
equal in this situation), then a "Routine" is preempted, being the lowest another domain, even if both domains are MLPP compliant networks.
level on that interface. Which one is up to that vendor's product
algorithm. At some point, the IETF might suggest a common mechanism for
this choice for consistency.
MLPP [2] also established the Alternative Party, and the Non-Preemptable MLPP [2] also established the Alternative Party, and the Non-
Resources options. The Alternative Party option is pre-configured to a Preemptable Resources options. The Alternative Party option is pre-
secondary phone to ring in the times where the original phone is being configured to a secondary phone to ring in the times where the
used. This can prevent a preemption event, even when that new inbound MLPP original phone is being used. This can prevent a preemption event,
call is of higher precedence. The Alternative Party must answer before the even when that new inbound MLPP call is of higher precedence. The
Timer T sub K expires. Additionally, a party of a phone can preset their Alternative Party must answer before the Timer T sub K expires.
phone with the option of æNon-Preemptable ResourcesÆ. This prevents Access Additionally, a party of a phone can preset their phone with the
Preemption events, but does not prevent Network Preemption events. option of 'Non-Preemptable Resources'. This prevents Access
Preemption events, but does not prevent Network Preemption events.
The Alternative Party redirect MUST be to a valid domain address and is The Alternative Party redirect MUST be to a valid domain address and
RECOMMENDED to a location which always answers the phone, such as a is RECOMMENDED to a location which always answers the phone, such as
operator or ACD pool of personnel. A limit in [12] set the maximum number a operator or ACD pool of personnel. A limit in [11] set the maximum
of call diversions to 5. An additional benefit to the Timer T sub K is number of call diversions to 5. An additional benefit to the Timer T
that it limits the time of these diversions when it expires for a call. sub K is that it limits the time of these diversions when it expires
The example below give this mechanism more clarity. for a call. The example below give this mechanism more clarity.
3.3 Access Preemption Event 3.3 Access Preemption Event
The following is a CSN example from [2] of the MLPP mandated process for The following is a CSN example from [2] of the MLPP mandated process
how Access-based Preemption events MUST occur, similar to a flow chart: for how Access-based Preemption events MUST occur, similar to a flow
chart:
Polk Page [8]
Scenario #1: Caller A and D are on an MLPP call when Caller C calls D Scenario #1: Caller A and D are on an MLPP call when Caller C calls D
IP Phone A IP Phone A
\ \
\ \
EOS =====> IP Phone D EOS =====> IP Phone D
/ /
/ /
IP Phone C IP Phone C
Figure 1. Call A-D exists when C calls D Figure 1. Call A-D exists when C calls D
If there is an existing call between two parties (A & D), and a third If there is an existing call between two parties (A & D), and a
party (C) calls into D (provided there is no congestion between C & D), third party (C) calls into D (provided there is no congestion
D (at the EOS) first checks the Precedence of this new inbound call. If between C & the EOS directly connected to D), the EOS (which is
the Precedence value is equal to or less than that of the existing call attached to D) first checks the Precedence of this new inbound
between D & A, then C either is returned a Disconnect (user busy), or is call. If the Precedence value is equal to or less than that of the
diverted to an alternate party (another phone) if there is one existing call between D & A, then C either is returned a
specified; C is Disconnect (Precedence Call Blocked indication) if one Disconnect (user busy), or is diverted to an alternate party
isn't specified. (another phone) if there is one specified; C is returned a
Disconnect (Precedence Call Blocked indication) if an alternate
party isn't specified.
If the MLPP call from C has a greater Precedence value than the A to D If the MLPP call from C has a greater Precedence value than the A
call, then a determination is made at D (at the EOS) whether D is to D call, then a determination is made for D (by the EOS
Preemptable. If D is not Preemptable, then an alternate party is looked connected to D) whether D is Preemptable. If D is not Preemptable,
for. If there is identified, the call is diverted. If it is not, C is then an alternate party is looked for. If an alternate party is
returned a Disconnect (Not Equipped for Preemption). If D is set up within the EOS for D, the call is diverted to this
Preemptable, the user and device of D is notified. So is the Device A. alternate party. If there is not one set up within the EOS for D,
The device at D is offered with Call Setup information, while also C is returned a Disconnect (Not Equipped for Preemption). If D is
starting the T sub K timer (defined as being between 4-30 seconds). A Preemptable, the user and device of D is notified. So is Device A.
Disconnect is sent to A now, placing it in the Idle state for at least The device at D is offered Call Setup information, while also
the moment. The device at D is waiting for the user at D to determine 1 starting the T sub K timer (defined as being between 4-30
of 3 possible paths to take: seconds). A Disconnect is sent to A now, releasing it from the A-
to-D call. The device at D is waiting for the user at D to
determine 1 of 3 possible paths to take:
Path #1 is when nothing occurs until the T sub K timer expires. This Path #1 is when nothing occurs until the T sub K timer expires.
results in a determination if an alternate party was specified by D. If This results in a determination if an alternate party was
there is, C is then connected to this alternate party. [12] stipulates specified by D. If there is, C is then connected to this alternate
a maximum number of 5 call diversions can occur. If not, C's call is party. [11] stipulates a maximum number of 5 call diversions can
normally set-up into D. occur. If no alternate party is specified, C's call is normally
set-up into D.
Path #2 is if there is a request from C to Clear the call. This results Path #2 is if there is a request from C to Clear the call. This
in A, C, and D being idle now. results in C and D being released now (A has already been
released).
Path #3 is when D acknowledges the inbound Preemption by C, thereby Path #3 is when D acknowledges the inbound Preemption by C,
accepting the call from C. This stops the T sub K timer. The Call is thereby accepting the call from C. This stops the T sub K timer.
set-up between C to D.
Polk Page [9]
The Call is set-up between C to D.
3.4 Network Preemption Event 3.4 Network Preemption Event
The following is a CSN example from [2] of the MLPP mandated process for The following is a CSN example from [2] of the MLPP mandated process
how Network-based Preemption events MUST occur, similar to a flow chart: for how Network-based Preemption events MUST occur, similar to a
flow chart:
Scenario #2: Caller A and B are on an MLPP call when Caller C initiates Scenario #2: Caller A and B are on an MLPP call when Caller C
a higher precedence call to Caller D (than the existing one between A initiates a higher precedence call to Caller D (than
and B) the existing one between A and B)
IP Phone A IP Phone B IP Phone A IP Phone B
\ / \ /
EOS 1 EOS 2 EOS 1 EOS 2
\ / \ /
TS 1 <=========> TS 2 TS 1 <=========> TS 2
/ \ / \
EOS 3 EOS 4 EOS 3 EOS 4
/ \ / \
IP Phone C IP Phone D IP Phone C IP Phone D
Figure 2. Call A-B exists when C calls D Figure 2. Call A-B exists when C calls D
If there is an existing MLPP call between two parties (A & B), and a new If there is an existing MLPP call between two parties (A & B), and
MLPP call (C-D) has a higher Precedence level than the A-B call (shown a new MLPP call (C-D) is signaled through the MLPP network (shown
between TSÆs 1 and 2 in Figure 2 above), the network first checks to see between TS's 1 and 2 in Figure 2 above), the network first checks
if there are available resources for that new call between the two new to see if there are available resources for that new call between
parties (C & D); if there is, everything works as if both calls were on the two new parties (C & D); if there is, everything works as if
the same Precedence level with no congestion. But if there is congestion both calls were on the same Precedence level with no congestion.
at any common interface between the calls A-B this new call C-D, there But if there is congestion at any common interface between the
is now a search at that interface for Preemptable resources (any call calls A-B this new call C-D, there is now a search at that
with a lower Precedence level than this new C-D call attempt). If there congested interface for Preemptable resources (any call with a
is not, a determination is made whether the Call from C is a Precedence lower Precedence level than this new C-D call attempt). If there
call. If the call from C is not, C is returned from the network a is not, a determination is made whether the Call from C is a
"Disconnect: Network Resources Unavailable" indication. If the call from Precedence call. If the call from C is not, C is returned from the
C is a Precedence Call, C is returned a "Disconnect: Precedence Call network a "Disconnect: Network Resources Unavailable" indication.
Blocked" indication. The call remains between A and B through both If the call from C is a Precedence Call, C is returned a
cases. "Disconnect: Precedence Call Blocked" indication. The call remains
between A and B through both cases.
If, there are preemptable resources available at the shared If the congested interface is the trunk interface of TS 1
interface for calls A-B and C-D (with C-D having a higher Precedence (connected to TS 2), there are common resources for both calls. In
level than A-B), A is notified of Preemption (without knowing where the case where TS 1 determines that the established call between
from). At the same time B is notified of Preemption (also without A-B is of lower precedence value than the new call set-up between
knowing where from). The network now releases (disconnects, clears) the C-D, A and B are notified of preemption and TS 1 now releases
amount of resources in order to have the C-D call be set-up normally. (disconnects, clears) the amount of resources at that congested
interface in order to have the C-D call be set-up normally. Phone
A and B are not notified from where the preemption occurred from.
Under this Network Preemption scenario within MLPP, the amount of Polk Page [10]
resources necessary for this call C-D, even if it requires more than one Under this Network Preemption scenario within MLPP, the amount of
other call to be preempted, MUST be made to satisfy the higher precedence resources necessary for this call C-D, even if it requires more than
call completion. All necessary lower Precedence level resources MUST be one other call to be preempted, MUST be made to satisfy the higher
cleared for any higher Precedence Call. precedence call completion. All necessary lower Precedence level
resources MUST be cleared for any higher Precedence Call.
4.0 MLPP over IP Basic Model 4.0 MLPP/IP Basic Model
Figure 3 (below) is a basic model of an MLPP over IP (MLPPoIP) domain Figure 3 (below) is a basic model of an MLPP over IP (MLPP/IP)
connected to both an MLPP CSN domain where the above requirements MUST be domain connected to both an MLPP CSN domain where the above
extended throughout, and to the public GSTN where the above requirements requirements MUST be extended throughout, and to the public CSN
cease at the edge of the MLPPoIP network at GW#1. Additionally, Phone A where the above requirements cease at the edge of the MLPP/IP
will start an MLPPoIP aware call at GW#1, likely with a minimum precedence network at GW#1. Additionally, Phone A will start an MLPP/IP aware
value, just as is deployed today within existing MLPP networks where the call at GW#1, likely with a minimum precedence value, just as is
entrance to an MLPP network is precedence marked "routine", with no deployed today within existing MLPP networks where the entrance to
possibility of upgrading or requesting higher precedence values for that an MLPP network is precedence marked "routine", with no possibility
call. of upgrading or requesting higher precedence values for that call.
GW#1--GSTN Circuit network -- Phone GW#1-- Public CSN -- Phone
/ A / A
UA#1 ----- MLPPoIP Domain (or federation of domains) /
UA#1 ----- MLPP/IP Domain (or federation of domains)
/ | \ / | \
Proxy UA#2 GW#2-- MLPP CSN --- Phone / | \
Server B Proxy | GW#2-- MLPP CSN ---- Phone
Server UA#2 B
Figure 3. Generic MLPP-MLPPoIP-GSTN Interworking model Figure 3. Generic MLPP-MLPP/IP-CSN Interworking model
The MLPP/IP portion of the network above is part of the MLPP CSN
network domain (via GW#2). The MLPP domain boundary is at GW#1.
4.1 Components of the Basic Model 4.1 Components of the Basic Model
Figure 1 shows several components in the diagram. The generic scope of Figure 1 shows several components in the diagram. The generic scope
each is as follows: of each is as follows:
UA's 1 & 2 SIP user agents; UA's 1 & 2 SIP user agents;
Phone A MLPP-based phone that exists within and adheres to Phone A MLPP-based phone that exists within and adheres
the MLPP specifications as written in [2&3] and to the MLPP Standards as written in [2&3]
those connected directly to EOSÆs; and those connected directly to EOS's;
Phone B TDM-based phone which could be one from a corporate Phone B TDM-based phone which could be one from a
network, private network or residential corporate network, private network or residential
Gateway#1 Seamless translator between the GSTN communications Gateway#1 Seamless translator between the public CSN
methods and the MLPPoIP domain communications methods and the MLPP/IP domain
Gateway#2 Seamless translator between the MLPP communications Polk Page [11]
methods specified in [2&3] and the MLPPoIP Gateway#2 Seamless translator between the MLPP
domain communications methods specified in [2&3] and the
MLPP/IP domain
Proxy Server SIP-based Server serving the functions defined in Proxy Server SIP-based Server serving the functions defined in
[1] [1]
There is not mention of the details within each network-type (MLPPoIP or There is not mention of the details within each network-type
GSTN) for the purposes of keeping this explanation a simple a possible; (MLPP/IP or CSN) for the purposes of keeping this explanation a
the burden should mostly fall on the Gateways to seamlessly translate the simple a possible; the burden should mostly fall on the Gateways to
communications from one type of network to the adjacent type. seamlessly translate the communications from one type of network to
the adjacent type.
5.0 SIP Multilevel Precedence and Preemption Requirements 5.0 SIP Multilevel Precedence and Preemption Requirements
The previous section explained the operational conditions needed in an Section 3 explained the operational conditions needed in an MLPP
MLPP circuit-switched infrastructure. The following are the requirements circuit-switched infrastructure. The following are the requirements
SIP for the interoperating with existing MLPP CSN infrastructures, as well SIP for the interoperating with existing MLPP CSN infrastructures,
as on SIP for operating within a IP based domain or federation of domains as well as on SIP for operating within a IP based domain or
with MLPP functionality: federation of domains with MLPP functionality:
REQ# - There MUST be a means by which the user of a UAC can select a REQ#1 - There MUST be a means by which the user of a UAC can select
precedence level for a session. This is not to be a user a precedence level for a session. This requirement is
priority, but a priority that will influence behaviors of User calling for a mechanism of session resource priority that
Agent and gateway resources will influence behaviors of User Agent and gateway
resources.
[2] specifies the precedence values as: [2] specifies the precedence values as:
Priority ISDN Text Priority ISDN Text
Level Sequence Sequence Level Sequence Sequence
--- ---- -------- --- ---- --------
1 "0000" = "Flash Override" (highest level) 1 "0000" = "Flash Override" (highest level)
2 "0001" = "Flash" 2 "0001" = "Flash"
3 "0010" = "Immediate" 3 "0010" = "Immediate"
4 "0011" = "Priority" 4 "0011" = "Priority"
5 "0100" = "Routine" (lowest level) 5 "0100" = "Routine" (lowest level)
"0101 û 1111" are unspecified "0101 - 1111" are unspecified
However SIP or SIPPING chooses to actually solve this binding between MLPP However SIP or SIPPING chooses to actually solve this binding
in ISDN and SIP message (Headers or something else), at least 5 distinct between MLPP in ISDN and SIP message (Headers or something else), at
and relative precedence levels MUST be maintained to ensure least 5 distinct and relative precedence levels MUST be maintained
interoperability. to ensure interoperability with existing networks.
Further, if more relative levels are chosen within SIP, a binding of these Further, if more relative levels are chosen within SIP, a binding of
5 ISDN levels to the higher precedence or priority levels MUST be these 5 ISDN levels to the higher precedence or priority levels MUST
maintained throughout a domain (or federation of domains) to ensure be maintained throughout a domain (or federation of domains) to
interoperability. ensure interoperability.
REQ#1 - This precedence choice by the UAC SHOULD be able to influence Polk Page [12]
Proxy Server behavior. The choice of whether this function is REQ#2 - This precedence choice by the UAC SHOULD be able to
utilized should be a matter of local policy. influence Proxy Server behavior. The choice of whether this
function is utilized should be a matter of local policy.
REQ#2 - The precedence levels available to the user of a SIP entity REQ#3 - The precedence levels available to the user of a SIP entity
should be limited to only those levels granted that user within should be limited to only those levels granted that user
that domain (or federation of domains). Each MLPP over IP within that domain (or federation of domains). Each MLPP/IP
infrastructure SHOULD have an mechanism to authenticate and then infrastructure SHOULD have an mechanism to authenticate and
authorize the use of precedence levels other than the "routine" then authorize the use of precedence levels other than the
(or default "normal" level for everyday voice communications). "routine" (or default "normal" level for everyday voice
This might be mandatory in some domains, but that assignment is communications). This might be mandatory in some domains,
policy, and should be left for local administration (and not but that assignment is policy, and should be left for local
part of this document). administration (and not part of this document).
REQ#3 - Once a precedence level has been chosen and the SIP Request REQ#4 - Once a precedence level has been chosen and the SIP Request
transmitted, the precedence level (however signified within the transmitted, the precedence level (however signified within
message) MUST be maintain for the duration of that session. The the message) MUST be maintained for the duration of that
UAS cannot reset this precedence level within the SIP response. session. The UAS cannot alter this precedence level within
the SIP response.
REQ#4 - User migration from a CSN infrastructure to an IP infrastructure REQ#5 - User migration from a CSN infrastructure to an IP
should not impact user behavior with reduced capabilities. SIP infrastructure should not impact user behavior with reduced
GWs MUST maintain the precedence level chosen that originate capabilities. SIP GWs MUST maintain the precedence level
within a MLPP enabled MLPP CSN network. This configuration will chosen that originate within a MLPP enabled CSN network.
be from a CSN to IP transition, and the users shouldn't expect a This configuration will be from a CSN to IP transition, and
loss in preferential treatment. the users shouldn't expect a loss in preferential
treatment.
REQ#5 - SIP GWs SHOULD set all there GSTN side received calls to the REQ#6 - SIP GWs SHOULD set all the (non-IP side) received calls to
minimum precedence setting, for that is no way of the minimum precedence setting, for there is no reasonable
authenticating a GSTN call is from a user authorized for means of authenticating a CSN call is from a user
higher precedence levels authorized for higher precedence levels
REQ#6 - Any session SHOULD be considered independent to the session REQ#7 - Any session SHOULD be considered independent to the session
initiated before it and the one after it from a precedence initiated before it and the one after it from a precedence
setting point of view. setting point of view.
REQ#7 - There MUST be some means of identifying each domain within the REQ#8 - There MUST be some means of identifying a domain of origin,
SIP message. or a domain for the use of this precedence level set within
the SIP message.
This is to ensure those SIP entities that are enabled for preferential This is to ensure those SIP entities that are enabled for
treatment based on the precedence level present within the SIP message preferential treatment based on the precedence level present within
have a means of easily differentiating those requests that are from their the SIP message have a means of easily differentiating those
domain and those that are not. requests that are from their domain and those that are not.
REQ#8 - There SHOULD be a means in which a UAS can authenticate the REQ#9 - There SHOULD be a means in which a UAS can authenticate the
included precedence level within a SIP Request. This should not included precedence level within a SIP Request. This should
burden the UAS to authenticate each and every UAC possible of not burden the UAS to authenticate each and every UAC
sending SIP Requests. possible of sending SIP Request messages. It is only
relevant to the UAS that an authorized precedence label is
This is specifically to address Access Preemption Events in which local Polk Page [13]
policy could mandate the preemption of an existing session in lieu of a included within an INVITE, and not the identity of the UAC
higher precedence level in this new SIP Request sending the INVITE.
REQ#9 - The User of a UAC SHOULD be able to remain anonymous, therefore This requirement is specifically to address Access Preemption Events
there MUST be a means by which an anonymous SIP Request can be in which local policy could mandate the preemption of an existing
authenticated by the UAS receiving the request. This requirement session in lieu of a higher precedence level in this new SIP
should also apply to Proxies. Request.
REQ#10 - There SHOULD be a means by which a UAC can use there precedence REQ#10 - The User of a UAC MAY be able to remain anonymous,
level to signal QOS, or that the UAC can react to an error therefore there MUST be a means by which an anonymous UAC
which was sent by a UAS requiring QOS for that session, with can transmit a SIP Request that can be authenticated by the
the indication within that error of which QOS (perhaps a level UAS receiving the request. This requirement should also
within itself) to use. apply to Proxies.
REQ#11 - The SIP and SIPPING WGs should investigate how SIP can help in REQ#11 - There SHOULD be a means by which a UAC can signal QOS, or
providing Network Preemption Events, but this is not a direct that the UAC can react to an error which was sent by a UAS
requirement here. requiring QOS for that session, with the indication within
that error of which QOS (perhaps a level within itself) to
use.
REQ#12 - All SIP entities that do not recognize the means in which a SIP This requirement will address Network Preemption Events within IP
message indicates precedence, or which domain the precedence infrastructures.
level is from, MUST ignore the means but not fail the SIP
Request based solely on that criteria. This applies to SIP UAs,
SIP GWs and SIP servers.
REQ#13 - There SHOULD be a mechanism in which any MLPP over IP domain REQ#12 - All SIP entities that do not recognize the means in which a
can determine the functional and configuration capabilities for SIP message indicates precedence, or which domain the
Registering UAs to ensure each can behave as the domain MIGHT precedence level is from, MUST ignore the indication but
mandate. not fail the SIP Request based solely on that criteria.
This applies to SIP UAs, SIP GWs and SIP servers.
REQ#14 - An SLA SHOULD solve all interoperability decisions regarding a REQ#13 - There SHOULD be a mechanism in which any MLPP/IP domain can
federation of domains internetworking. determine the functional and configuration capabilities for
Registering UAs to ensure each can behave as the domain
MIGHT mandate.
REQ#14 - Call Detail Records SHOULD be kept within a SIP entity
within an MLPP/IP infrastructure to ensure an
administrative means for addressing various misuses of
precedence calling.
6.0 IANA Considerations 6.0 IANA Considerations
There are no IANA considerations requested with this document There are no IANA considerations requested with this document
7.0 Security Considerations 7.0 Security Considerations
This topic is chalk full of security concerns. However, this document is This topic is chock full of security concerns. However, this
not requesting capabilities that are to be implemented on the open document is not requesting capabilities that are to be implemented
Internet. The intention for SIP to extend itself to meet these on the open Internet. The intention here is for SIP to extend itself
requirements is for interoperation and transition with existing closed to meet these requirements for interoperation and transition with
networks that are MLPP enabled; which are few, yet very large (in the
millions of endpoints). The current safeguard for MLPP signaling leaking
into other networks is the domain identifier.
Further, some requirements stated here call for the authentication Polk Page [14]
abilities of the receiving UAS (or Proxy) of a SIP message with a existing closed networks that are MLPP enabled; which are few, yet
precedence level indication to the UAC. If this authentication, or more very large.
accurately authenticated authorization doesnÆt pass, the precedence level
request should be ignored. Existing MLPP enabled domains will likely fail
the session for many reasons, this one being only one of them. User
authentication to their networks will be mandated, and policed heavily.
Properly build infrastructures with these capabilities should not Further, some requirements stated here call for the authentication
influence the Internet or stray SIP Proxies that process non-MLPP over IP abilities of the receiving UAS (or Proxy) of a SIP message with a
transactions. precedence level indication to the UAC. If this authentication, or
more accurately authenticated authorization doesnÆt pass, the
precedence level request should be ignored. Existing MLPP enabled
domains will likely fail the session for many reasons, this one
being only one of them. User authentication to their networks will
be mandated, and policed heavily.
Certain domains will likely mandate that all UAs conform to this Properly built infrastructures with these capabilities should not
functionality in order to communicate, with appropriate challenges influence the Internet or individual SIP Proxies that process non-
configured at each SIP entity to prevent unwanted or disallowed SIP MLPP transactions.
communications.
Certain domains will likely mandate that all SIP entities conform to
these functionalities in order to communicate, with appropriate
challenges configured at each SIP entity to prevent unwanted or
disallowed SIP communications.
8.0 Acknowledgements 8.0 Acknowledgements
Your name here To Mike Pierce and Janet Gunn for their insightful comments in
framing this document
9.0 References 9.0 References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "Session Peterson, J., Sparks, R., Handley, M. and E. Schooler, "Session
Initiation Protocol", RFC 3261, June 2002 Initiation Protocol", RFC 3261, June 2002
[2] ANSI specification ANSI T1.619-1992. [2] ANSI T1.619-1992 (R1999)
[3] ANSI specification ANSI T1.619A-1994. [3] ANSI T1.619a-1994 (R1999)
[4] "Generic Switching Center Requirements" (GSCR), JIEO Technical [4] "Generic Switching Center Requirements" (GSCR), JIEO Technical
Report 8249, March 1997 Report 8249, March 2003
[5] Defense Switched Network "Generic Switching Test Plan" (GSTP), [5] Defense Switched Network "Generic Switching Test Plan" (GSTP),
June 1999 June 1999
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[7] ITU-T Recommendation Q.735.3 (1993), "Description for Community [7] ITU-T Recommendation Q.735.3 (1993), "Description for Community
of Interest Supplementary Services using SS7 - Multilevel precedence of Interest Supplementary Services using SS7 - Multilevel
and preemption" precedence and preemption"
[8] ANSI T1.604-1990 "Integrated Services Digital Network (ISDN)",
[9] T1.113-1988 "Signaling System Number 7 (SS7) û ISDN User Part" Polk Page [15]
[10] ANSI T1.604-1990 "ISDN û Layer 3 Signaling Specification for [8] ANSI T1.604-1990 "ISDN - Layer 3 Signaling Specification for
Circuit-Switched Bearer service for Digital Subscriber System Circuit-Switched Bearer service for Digital Subscriber System
Number 1 (DSS1)" Number 1 (DSS1)"
[11] ANSI T1.610-1990 "DSS1 û Generic Procedures for the Control of [9] T1.113-2000 "Signaling System Number 7 (SS7) - ISDN User Part"
ISDN Supplementary Services"
[12] ITU-T Recommendation I.255.3 (1990), "Multilevel precedence [10] ANSI T1.610-1990 (R2000) "DSS1 - Generic Procedures for the
Control of ISDN Supplementary Services"
[11] ITU-T Recommendation I.255.3 (1998), "Multilevel precedence
and preemption service (MLPP)". and preemption service (MLPP)".
10.0 Author Information 10.0 Author Information
James M. Polk James M. Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, Texas 75082 USA Richardson, Texas 75082 USA
jmpolk@cisco.com jmpolk@cisco.com
"Copyright (C) The Internet Society (February 23rd, 2001). 11. Full Copyright Statement
All Rights Reserved.
This document and translations of it may be copied and furnished to "Copyright (C) The Internet Society (February 23rd, 2001).
others, and derivative works that comment on or otherwise explain it or All Rights Reserved.
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 This document and translations of it may be copied and furnished to
revoked by the Internet Society or its successors or assigns. 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.
This document and the information contained herein is provided on an "AS The limited permissions granted above are perpetual and will not be
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK revoked by the Internet Society or its successors or assigns.
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."
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."
Polk Page [16]
The Expiration date for this Internet Draft is: The Expiration date for this Internet Draft is:
August 24th, 2003 Dec 30th, 2003
Polk MLPP Requirements for SIP Page [17]
 End of changes. 129 change blocks. 
560 lines changed or deleted 578 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/