Internet Engineering Task Force James M. Polk
Internet Draft Cisco Systems
Expiration: Dec 30th, 2003
File: draft-polk-sipping-mlpp-reqs-01.txt
Multilevel Precedence and Preemption
in the Session Initiation Protocol
June 30th, 2003
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Abstract
This document proposes considerations and requirements for the
extension of the Session Initiation Protocol (SIP) [1] to support
Multi-Level Precedence and Preemption (MLPP) functionality
originally set forth in [2&3]. This document will be limited in
scope to the requirements of the SIP Protocol; MLPP within the IETF,
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]
Internet Draft MLPP Requirements for SIP June 30th, 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions used in this document . . . . . . . . . . . 3
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4
3. MLPP Operational Functionality . . . . . . . . . . . . . . . 5
3.1 MLPP Precedence . . . . . . . . . . . . . . . . . . . . 6
3.2 Operational Behavior for Preemption . . . . . . . . . . 7
3.2.1 Modes of Preemption in CSN Systems . . . . . . . . . . 7
3.3 Access Preemption Event . . . . . . . . . . . . . . . . 8
3.4 Network Preemption Event . . . . . . . . . . . . . . . 10
4. MLPP/IP Basic Model . . . . . . . . . . . . . . . . . . . . . 11
4.1 Components of the Basic Model . . . . . . . . . . . . . 11
5. SIP Multilevel Precedence and Preemption Requirements . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Author Information . . . . . . . . . . . . . . . . . . . . . 16
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
1.0 Introduction
This document proposes considerations and requirements for the
extension of the Session Initiation Protocol (SIP) [1] to support an
IP version of Multi-Level Precedence and Preemption (MLPP)
functionality originally set forth in [2&3]. This document will be
limited in scope to aspects having to do with the SIP Protocol. MLPP
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
service" in combination with ISDN supplementary services. MLPP has
two very simple concepts for voice and video (Real-Time)
communications:
A) labeling or marking every call (at inception) with a
Precedence level relative to other calls within a single
administrative domain, or federation of domains; and
B) during times of congestion at any point in the network, the
device experiencing congestion will determine if preempting
(seizing) the resources of any identifiable lower relative
priority call(s) is required to properly set-up a newly
signaled higher priority call
Polk Page [2]
Internet Draft MLPP Requirements for SIP June 30th, 2003
This administrative control and network functionality exists today
in several large deployments. It is based, or founded, in US
Government network requirements. MLPP [2, 3] is a supplementary
service to ISDN [8, 9, 10]. Several other non-US networks have been
enabled with this MLPP functionality in the past decade. Most of
these networks are looking to incorporate IP signaling and transport
of their voice and video services and require the MLPP functionality
during the transition and progression/evolution of their networks in
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
services only. In the future, Instant Messaging and email are
targets for this capability as well, but will not be further
discussed within this document.
This document will focus on the considerations and requirements on
SIP Proxies, Gateways and User Agents, concentrating on what needs
to be addressed to enable MLPP functionality.
Considerations need to be met and realized in the user experience of
the existing MLPP service. Because of the existing size of these
networks (one network has several million end-stations), the
migration of their communications over to an IP based system cannot
occur quickly. With this in mind, many considerations should be kept
in mind that this is not a brand new installation. Further, all new
implementations of IP endpoints with MLPP functionality will be
replacing the old infrastructure (and endpoints).
Most of the requirements here have been taken from [2&3]. Any
remaining details and concepts attained from documents came from the
certification materials which all products must be tested against to
achieve MLPP compliance and interoperability status in [4&5]. There
are a few concepts mentioned here that were attained from
interviewing users and testers of MLPP for guidance of how this
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. Also included will be an overview of the current
decision process that exists within the MLPP enabled network. This
will be followed by the SIP(PING) requirements for enabling this
functionality in this working group.
1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [6].
Polk Page [3]
Internet Draft MLPP Requirements for SIP June 30th, 2003
2.0 Terms and Definitions
The following is a list of definitions and conventions to used
throughout this document. Note that some of the definitions are
either MLPP *or* IP centric, and might not make sense to the other.
Advice is taking these words in the context of the section of this
document they are written in.
Alternate Party is the party to which a precedence call will be
diverted. Diversion will occur either when the
response timer T-sub-k expires, when the called
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
infrastructure using circuit-switched technology,
such as provided by TDM transmission facilities,
rather than packet technologies; most often this
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
entity
End Office Node EN - see EOS
End Office Switch EOS - An MLPP capable circuit switching system
configured to interconnect user lines and trunks
ISDN Integrated Services Digital Network
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
about to place has available resources for call
completion
MLPP Multi-level Precedence and Preemption [2&3] - ANSI
T1.619 and 619A Standards stipulating mechanisms
for marking each voice communication with a
Precedence level, and defining the requirement for
the Preemption of existing lower Precedence
sessions during congestion in favor of new higher
Precedence session(s)
Polk Page [4]
Internet Draft MLPP Requirements for SIP June 30th, 2003
Multifunction Switch MFS - A combination of a End Office Switch (EOS)
and Tandem Switch (TS); having trunking and CPE
connection capabilities within one, more
economical unit
Precedence The relative priority level assigned to each call
by the caller at inception
Precedence Call Any call that has a Precedence level higher than
Routine
Preempt Notification The audible notification sent to all endstations
who have been preempted for any reason
Preempted Any caller who has had their existing call cleared
Or disconnected
Preempting Call A call with a Precedence level higher than others
on a specified interface at a time of congestion
Registrar Server SIP Server [1] that serves as a Registration point
principally for mobility
Response Timer T-sub-K Is started when the network notifies the Called
device of a inbound precedence call; acceptance
must occur by the Called device; the timer is
specified in [2] at from 4-30 seconds
Response Timer T-sub-L Is started when an LFB information unit is sent
into the network to establish an open path between
the Calling endstation and the intended called
endstation; the timer is expected in [2] as from
5û20 seconds
Tandem Switch TS - Only connects to EOS's and other TS's; is the
primary backbone of a circuit-switched MLPP
Network
3.0 MLPP Operational Functionality
This section will provide the operational functionality of an MLPP
infrastructure. The requirements section later in this document will
be based on this section (and subsections) for its operational
requirements in SIP(PING).
The following subsections are from the core MLPP documents [2,3], as
well as the documents involving the actual testing of any component
for certification of MLPP compliance [4,5,7].
Polk Page [5]
Internet Draft MLPP Requirements for SIP June 30th, 2003
The root specification [2] states that there are two conceptual
parts to MLPP: Precedence and Preemption.
3.1 MLPP Precedence
Precedence means Priority. It is the relative priority of a call to
all other calls within that domain (or federation of domains if
applicable) when traversing any interface, including an endstation.
It is set or assigned by the calling party at the beginning of a
call, on a per call basis. Once the precedence level is chosen by a
caller, it cannot be changed for the duration of that call. The next
call being independent of the first call, can be made at another
authorized level, also chosen by the calling party.
The table below from [2] specifies the precedence values as:
Priority ISDN Text
Level Sequence Sequence
--- ---- --------
1 "0000" = "Flash Override" (highest level)
2 "0001" = "Flash"
3 "0010" = "Immediate"
4 "0011" = "Priority"
5 "0100" = "Routine" (lowest level)
"0101 - 1111" are unspecified
The possible levels the call can be assigned, in CSN MLPP
infrastructures, are bound to the allowable levels set on the switch
(EOS) for that line. Each line in this infrastructure is configured
to only allow certain levels to be chosen by anyone accessing that
phone. Someone with personal access to higher levels than that of
the phone they're in front of, needs to go to a phone with access to
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 the determination of which call or calls are preempted
(should congestion occur at any point or interface this call
traverses) as explained in the next section, the user of that phone
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
restraint no longer will exist. Thus, another means will be required
by SIP to restrict the unauthorized use of higher precedence calls
by those that are not allowed to signal these precedence values in
their INVITE messages.
An important background note, the determination of who is granted
Polk Page [6]
Internet Draft MLPP Requirements for SIP June 30th, 2003
permission to make precedence calls (meaning any call with a
precedence level higher than routine - the lowest level) is by job
function in most MLPP networks, and not by who they are, or how long
they've been with that organization. This is the case within the US
"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
Preemption (in a CSN case) is the seizing of otherwise used
resources of one or more calls in order to complete another call in
a congestion situation. The nodes that determine preemption are EOSs
or TNs in the CSN infrastructure. The decision is based on the
precedence values assigned to each circuit with the trunk groups on
those nodes. When a call is placed, the transiting node maintains
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 for available resources to route that call through. If the
node determines that it has no more outbound (egress) resources
available (for example on a T1 interface) for this new call, a
comparison is performed of this new call's precedence value to that
of all the other calls existing on that outbound interface. If this
new call has a higher precedence value than any one of the other
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
There are two modes of Preemption: preemption of the called device
with another inbound higher precedence call (Access Preemption
Event), and preemption at any point of congestion between non-
endpoint nodes within the network (Network Preemption Event).
MLPP is mandated in [2] as having call handling influence within 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. 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.
Polk Page [7]
Internet Draft MLPP Requirements for SIP June 30th, 2003
Here are the three preemption conditions:
a) 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)
b) The called party MUST acknowledge an inbound precedence call
before connection to that call;
c) Upon determination of no available resources and calls existing
on an interface of lower precedence, the lowest level call(s)
MUST be cleared in order to complete the higher precedence call;
A call can be preempted at any time after the precedence level has
been determined to be lower than the new call and before call
clearing has begun. However, no preemption of any resources shall
occur within a domain as a result of a call into that domain from
another domain, even if both domains are MLPP compliant networks.
MLPP [2] also established the Alternative Party, and the Non-
Preemptable Resources options. The Alternative Party option is pre-
configured to a secondary phone to ring in the times where the
original phone is being used. This can prevent a preemption event,
even when that new inbound MLPP call is of higher precedence. The
Alternative Party must answer before the Timer T sub K expires.
Additionally, a party of a phone can preset their phone with the
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 RECOMMENDED to a location which always answers the phone, such as
a operator or ACD pool of personnel. A limit in [11] set the maximum
number of call diversions to 5. An additional benefit to the Timer T
sub K is that it limits the time of these diversions when it expires
for a call. The example below give this mechanism more clarity.
3.3 Access Preemption Event
The following is a CSN example from [2] of the MLPP mandated process
for how Access-based Preemption events MUST occur, similar to a flow
chart:
Polk Page [8]
Internet Draft MLPP Requirements for SIP June 30th, 2003
Scenario #1: Caller A and D are on an MLPP call when Caller C calls D
IP Phone A
\
\
EOS =====> IP Phone D
/
/
IP Phone C
Figure 1. Call A-D exists when C calls D
If there is an existing call between two parties (A & D), and a
third party (C) calls into D (provided there is no congestion
between C & the EOS directly connected to D), the EOS (which is
attached to D) first checks the Precedence of this new inbound
call. If the Precedence value is equal to or less than that of the
existing call between D & A, then C either is returned a
Disconnect (user busy), or is diverted to an alternate party
(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 call, then a determination is made for D (by the EOS
connected to D) whether D is Preemptable. If D is not Preemptable,
then an alternate party is looked for. If an alternate party is
set up within the EOS for D, the call is diverted to this
alternate party. If there is not one set up within the EOS for D,
C is returned a Disconnect (Not Equipped for Preemption). If D is
Preemptable, the user and device of D is notified. So is Device A.
The device at D is offered Call Setup information, while also
starting the T sub K timer (defined as being between 4-30
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 results in a determination if an alternate party was
specified by D. If there is, C is then connected to this alternate
party. [11] stipulates a maximum number of 5 call diversions can
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 in C and D being released now (A has already been
released).
Path #3 is when D acknowledges the inbound Preemption by C,
thereby accepting the call from C. This stops the T sub K timer.
Polk Page [9]
Internet Draft MLPP Requirements for SIP June 30th, 2003
The Call is set-up between C to D.
3.4 Network Preemption Event
The following is a CSN example from [2] of the MLPP mandated process
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 a higher precedence call to Caller D (than
the existing one between A and B)
IP Phone A IP Phone B
\ /
EOS 1 EOS 2
\ /
TS 1 <=========> TS 2
/ \
EOS 3 EOS 4
/ \
IP Phone C IP Phone 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 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 if there are available resources for that new call between
the two new parties (C & D); if there is, everything works as if
both calls were on the same Precedence level with no congestion.
But if there is congestion at any common interface between the
calls A-B this new call C-D, there is now a search at that
congested interface for Preemptable resources (any call with a
lower Precedence level than this new C-D call attempt). If there
is not, a determination is made whether the Call from C is a
Precedence call. If the call from C is not, C is returned from the
network a "Disconnect: Network Resources Unavailable" indication.
If the call from C is a Precedence Call, C is returned a
"Disconnect: Precedence Call Blocked" indication. The call remains
between A and B through both cases.
If the congested interface is the trunk interface of TS 1
(connected to TS 2), there are common resources for both calls. In
the case where TS 1 determines that the established call between
A-B is of lower precedence value than the new call set-up between
C-D, A and B are notified of preemption and TS 1 now releases
(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.
Polk Page [10]
Internet Draft MLPP Requirements for SIP June 30th, 2003
Under this Network Preemption scenario within MLPP, the amount of
resources necessary for this call C-D, even if it requires more than
one other call to be preempted, MUST be made to satisfy the higher
precedence call completion. All necessary lower Precedence level
resources MUST be cleared for any higher Precedence Call.
4.0 MLPP/IP Basic Model
Figure 3 (below) is a basic model of an MLPP over IP (MLPP/IP)
domain connected to both an MLPP CSN domain where the above
requirements MUST be extended throughout, and to the public CSN
where the above requirements cease at the edge of the MLPP/IP
network at GW#1. Additionally, Phone A will start an MLPP/IP aware
call at GW#1, likely with a minimum precedence value, just as is
deployed today within existing MLPP networks where the entrance to
an MLPP network is precedence marked "routine", with no possibility
of upgrading or requesting higher precedence values for that call.
GW#1-- Public CSN -- Phone
/ A
/
UA#1 ----- MLPP/IP Domain (or federation of domains)
/ | \
/ | \
Proxy | GW#2-- MLPP CSN ---- Phone
Server UA#2 B
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
Figure 1 shows several components in the diagram. The generic scope
of each is as follows:
UA's 1 & 2 SIP user agents;
Phone A MLPP-based phone that exists within and adheres
to the MLPP Standards as written in [2&3]
and those connected directly to EOS's;
Phone B TDM-based phone which could be one from a
corporate network, private network or residential
Gateway#1 Seamless translator between the public CSN
communications methods and the MLPP/IP domain
Polk Page [11]
Internet Draft MLPP Requirements for SIP June 30th, 2003
Gateway#2 Seamless translator between the MLPP
communications methods specified in [2&3] and the
MLPP/IP domain
Proxy Server SIP-based Server serving the functions defined in
[1]
There is not mention of the details within each network-type
(MLPP/IP or CSN) for the purposes of keeping this explanation a
simple a possible; the burden should mostly fall on the Gateways to
seamlessly translate the communications from one type of network to
the adjacent type.
5.0 SIP Multilevel Precedence and Preemption Requirements
Section 3 explained the operational conditions needed in an MLPP
circuit-switched infrastructure. The following are the requirements
SIP for the interoperating with existing MLPP CSN infrastructures,
as well as on SIP for operating within a IP based domain or
federation of domains with MLPP functionality:
REQ#1 - There MUST be a means by which the user of a UAC can select
a precedence level for a session. This requirement is
calling for a mechanism of session resource priority that
will influence behaviors of User Agent and gateway
resources.
[2] specifies the precedence values as:
Priority ISDN Text
Level Sequence Sequence
--- ---- --------
1 "0000" = "Flash Override" (highest level)
2 "0001" = "Flash"
3 "0010" = "Immediate"
4 "0011" = "Priority"
5 "0100" = "Routine" (lowest level)
"0101 - 1111" are unspecified
However SIP or SIPPING chooses to actually solve this binding
between MLPP in ISDN and SIP message (Headers or something else), at
least 5 distinct and relative precedence levels MUST be maintained
to ensure interoperability with existing networks.
Further, if more relative levels are chosen within SIP, a binding of
these 5 ISDN levels to the higher precedence or priority levels MUST
be maintained throughout a domain (or federation of domains) to
ensure interoperability.
Polk Page [12]
Internet Draft MLPP Requirements for SIP June 30th, 2003
REQ#2 - This precedence choice by the UAC SHOULD be able to
influence Proxy Server behavior. The choice of whether this
function is utilized should be a matter of local policy.
REQ#3 - The precedence levels available to the user of a SIP entity
should be limited to only those levels granted that user
within that domain (or federation of domains). Each MLPP/IP
infrastructure SHOULD have an mechanism to authenticate and
then authorize the use of precedence levels other than the
"routine" (or default "normal" level for everyday voice
communications). This might be mandatory in some domains,
but that assignment is policy, and should be left for local
administration (and not part of this document).
REQ#4 - Once a precedence level has been chosen and the SIP Request
transmitted, the precedence level (however signified within
the message) MUST be maintained for the duration of that
session. The UAS cannot alter this precedence level within
the SIP response.
REQ#5 - User migration from a CSN infrastructure to an IP
infrastructure should not impact user behavior with reduced
capabilities. SIP GWs MUST maintain the precedence level
chosen that originate within a MLPP enabled CSN network.
This configuration will be from a CSN to IP transition, and
the users shouldn't expect a loss in preferential
treatment.
REQ#6 - SIP GWs SHOULD set all the (non-IP side) received calls to
the minimum precedence setting, for there is no reasonable
means of authenticating a CSN call is from a user
authorized for higher precedence levels
REQ#7 - Any session SHOULD be considered independent to the session
initiated before it and the one after it from a precedence
setting point of view.
REQ#8 - There MUST be some means of identifying a domain of origin,
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 treatment based on the precedence level present within
the SIP message have a means of easily differentiating those
requests that are from their domain and those that are not.
REQ#9 - There SHOULD be a means in which a UAS can authenticate the
included precedence level within a SIP Request. This should
not burden the UAS to authenticate each and every UAC
possible of sending SIP Request messages. It is only
relevant to the UAS that an authorized precedence label is
Polk Page [13]
Internet Draft MLPP Requirements for SIP June 30th, 2003
included within an INVITE, and not the identity of the UAC
sending the INVITE.
This requirement is specifically to address Access Preemption Events
in which local policy could mandate the preemption of an existing
session in lieu of a higher precedence level in this new SIP
Request.
REQ#10 - The User of a UAC MAY be able to remain anonymous,
therefore there MUST be a means by which an anonymous UAC
can transmit a SIP Request that can be authenticated by the
UAS receiving the request. This requirement should also
apply to Proxies.
REQ#11 - There SHOULD be a means by which a UAC can signal QOS, or
that the UAC can react to an error which was sent by a UAS
requiring QOS for that session, with the indication within
that error of which QOS (perhaps a level within itself) to
use.
This requirement will address Network Preemption Events within IP
infrastructures.
REQ#12 - All SIP entities that do not recognize the means in which a
SIP message indicates precedence, or which domain the
precedence level is from, MUST ignore the indication 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/IP domain can
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
There are no IANA considerations requested with this document
7.0 Security Considerations
This topic is chock full of security concerns. However, this
document is not requesting capabilities that are to be implemented
on the open Internet. The intention here is for SIP to extend itself
to meet these requirements for interoperation and transition with
Polk Page [14]
Internet Draft MLPP Requirements for SIP June 30th, 2003
existing closed networks that are MLPP enabled; which are few, yet
very large.
Further, some requirements stated here call for the authentication
abilities of the receiving UAS (or Proxy) of a SIP message with a
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.
Properly built infrastructures with these capabilities should not
influence the Internet or individual SIP Proxies that process non-
MLPP transactions.
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
To Mike Pierce and Janet Gunn for their insightful comments in
framing this document
9.0 References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "Session
Initiation Protocol", RFC 3261, June 2002
[2] ANSI T1.619-1992 (R1999)
[3] ANSI T1.619a-1994 (R1999)
[4] "Generic Switching Center Requirements" (GSCR), JIEO Technical
Report 8249, March 2003
[5] Defense Switched Network "Generic Switching Test Plan" (GSTP),
June 1999
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] ITU-T Recommendation Q.735.3 (1993), "Description for Community
of Interest Supplementary Services using SS7 - Multilevel
precedence and preemption"
Polk Page [15]
Internet Draft MLPP Requirements for SIP June 30th, 2003
[8] ANSI T1.604-1990 "ISDN - Layer 3 Signaling Specification for
Circuit-Switched Bearer service for Digital Subscriber System
Number 1 (DSS1)"
[9] T1.113-2000 "Signaling System Number 7 (SS7) - ISDN User Part"
[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)".
10.0 Author Information
James M. Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082 USA
jmpolk@cisco.com
11. Full Copyright Statement
"Copyright (C) The Internet Society (February 23rd, 2001).
All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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]
Internet Draft MLPP Requirements for SIP June 30th, 2003
The Expiration date for this Internet Draft is:
Dec 30th, 2003
Polk MLPP Requirements for SIP Page [17]