One document matched: draft-polk-sipping-mlpp-reqs-00.txt
Internet Engineering Task Force James M. Polk
Internet Draft Cisco Systems
Expiration: Aug 24th, 2003
File: draft-polk-sipping-mlpp-reqs-00.txt
Multilevel Precedence and Preemption
in the Session Initiation Protocol
February 24th, 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 an IP version of
Multi-Level Precedence and Preemption 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.
Polk Page 1
Internet Draft MLPP over IP in SIP Feb 24th, 2003
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions used in this document . . . . . . . . . . . . . . . 3
2.0 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . 4
3.0 MLPP Operational Functionality . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . 9
3.4 Network Preemption Event . . . . . . . . . . . . . . . . . . . . 10
4.0 MLPP over IP Basic Model . . . . . . . . . . . . . . . . . . . . 11
4.1 Components of the Basic Model . . . . . . . . . . . . . . . . . 12
5.0 SIP Multilevel Precedence and Preemption Requirements . . . . . 12
6.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
7.0 Security Considerations . . . . . . . . . . . . . . . . . . . . 15
9.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
10.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.0 Author Information . . . . . . . . . . . . . . . . . . . . . . . 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 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
point of congestion at the endpoint or internetworking device,
having that device 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
This administrative control and network functionality exists today in
several large deployments. It is based, or founded, in US Government
Polk Page 2
Internet Draft MLPP over IP in SIP Feb 24th, 2003
network requirements. [2,3] is an augmentation service to ANSIÆs ISDN
[8,9,10,11]. 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 with this
functionality with IP endpoints will be primary line endpoints, and not in
secondary configurations.
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 over IP in SIP Feb 24th, 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 another endstation which is configured for any
call diversion if the Called device has an inbound
Precedence inbound call while that Called User is
actively on a call/session
CSN Circuit Switched Network - public or private TDM
Infrastructure; most often this will refer to the
existing MLPP enabled closed network of within the
same domain, and not the publicly available dial
circuits
Domain A network under one single administrative control
entity, possibly non-adjacent geographically, meaning
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
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-
wide circuit-switched public telephony network
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 specifications 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
Polk Page 4
Internet Draft MLPP over IP in SIP Feb 24th, 2003
session(s)
MLPPoIP MLPP (functionality) over (an) IP network(s)
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,
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
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 end-
station; the timer is expected in [2] as from 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
Polk Page 5
Internet Draft MLPP over IP in SIP Feb 24th, 2003
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
replies to SIP requests. The response accepts,
rejects or redirects the request.
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 from the core MLPP documents [2,3] must be referenced in
detail, as well as the documents involving the actual testing of any
component for certification of MLPP compliance [4,5,7].
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,
is bound to the allowable levels set on the switch (or EOS) for that
circuit. 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
Polk Page 6
Internet Draft MLPP over IP in SIP Feb 24th, 2003
of, needs to go to a phone with access to those higher precedence levels
in order to make a higher precedence call.
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
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 that
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 within the network not involving either party of the preempted
call at all, but at a point of congestion (Network Preemption Event)
Polk Page 7
Internet Draft MLPP over IP in SIP Feb 24th, 2003
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
that inbound call before connection to that call;
o 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 existing 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.
A clarification must be stated: higher precedence provides preferential
call handling throughout an MLPP domain, regardless of how much higher a
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
or mechanism in the case of which one of several lower precedence calls
gets disconnected, where such a condition exists. Only such that the
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
connections existing, 1 "Flash" call, 1 "Immediate" and 4 "Routine" calls,
Polk Page 8
Internet Draft MLPP over IP in SIP Feb 24th, 2003
when another "Flash" level attempts to gain resources out that interface;
if that new "Flash" call is the same bandwidth as the others (all are
equal in this situation), then a "Routine" is preempted, being the lowest
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
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 [12] 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:
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 & D),
D (at the EOS) 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 Disconnect (Precedence Call Blocked indication) if one
isn't specified.
Polk Page 9
Internet Draft MLPP over IP in SIP Feb 24th, 2003
If the MLPP call from C has a greater Precedence value than the A to D
call, then a determination is made at D (at the EOS) whether D is
Preemptable. If D is not Preemptable, then an alternate party is looked
for. If there is identified, the call is diverted. If it is not, C is
returned a Disconnect (Not Equipped for Preemption). If D is
Preemptable, the user and device of D is notified. So is the Device A.
The device at D is offered with 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, placing it in the Idle state for at least
the moment. 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. [12] stipulates
a maximum number of 5 call diversions can occur. If not, 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 A, C, and D being idle now.
Path #3 is when D acknowledges the inbound Preemption by C, thereby
accepting the call from C. This stops the T sub K timer. 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) has a higher Precedence level than the A-B call (shown
between TSÆs 1 and 2 in Figure 2 above), the network first checks to see
Polk Page 10
Internet Draft MLPP over IP in SIP Feb 24th, 2003
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 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, there are preemptable resources available at the shared
interface for calls A-B and C-D (with C-D having a higher Precedence
level than A-B), A is notified of Preemption (without knowing where
from). At the same time B is notified of Preemption (also without
knowing where from). The network now releases (disconnects, clears) the
amount of resources in order to have the C-D call be set-up normally.
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 over IP Basic Model
Figure 3 (below) is a basic model of an MLPP over IP (MLPPoIP) domain
connected to both an MLPP CSN domain where the above requirements MUST be
extended throughout, and to the public GSTN where the above requirements
cease at the edge of the MLPPoIP network at GW#1. Additionally, Phone A
will start an MLPPoIP 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--GSTN Circuit network -- Phone
/ A
UA#1 ----- MLPPoIP Domain (or federation of domains)
/ | \
Proxy UA#2 GW#2-- MLPP CSN --- Phone
Server B
Figure 3. Generic MLPP-MLPPoIP-GSTN Interworking model
Polk Page 11
Internet Draft MLPP over IP in SIP Feb 24th, 2003
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 specifications 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 GSTN communications
methods and the MLPPoIP domain
Gateway#2 Seamless translator between the MLPP communications
methods specified in [2&3] and the MLPPoIP
domain
Proxy Server SIP-based Server serving the functions defined in
[1]
There is not mention of the details within each network-type (MLPPoIP or
GSTN) 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
The previous section 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# - There MUST be a means by which the user of a UAC can select a
precedence level for a session. This is not to be a user
priority, but a 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"
Polk Page 12
Internet Draft MLPP over IP in SIP Feb 24th, 2003
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.
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.
REQ#1 - 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#2 - 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 over 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#3 - Once a precedence level has been chosen and the SIP Request
transmitted, the precedence level (however signified within the
message) MUST be maintain for the duration of that session. The
UAS cannot reset this precedence level within the SIP response.
REQ#4 - 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 MLPP CSN network. This configuration will
be from a CSN to IP transition, and the users shouldn't expect a
loss in preferential treatment.
REQ#5 - SIP GWs SHOULD set all there GSTN side received calls to the
minimum precedence setting, for that is no way of
authenticating a GSTN call is from a user authorized for
higher precedence levels
REQ#6 - 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#7 - There MUST be some means of identifying each domain within the
SIP message.
Polk Page 13
Internet Draft MLPP over IP in SIP Feb 24th, 2003
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#8 - 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 Requests.
This 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#9 - The User of a UAC SHOULD be able to remain anonymous, therefore
there MUST be a means by which an anonymous SIP Request can be
authenticated by the UAS receiving the request. This requirement
should also apply to Proxies.
REQ#10 - There SHOULD be a means by which a UAC can use there precedence
level to 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.
REQ#11 - The SIP and SIPPING WGs should investigate how SIP can help in
providing Network Preemption Events, but this is not a direct
requirement here.
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 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
can determine the functional and configuration capabilities for
Registering UAs to ensure each can behave as the domain MIGHT
mandate.
REQ#14 - An SLA SHOULD solve all interoperability decisions regarding a
federation of domains internetworking.
6.0 IANA Considerations
There are no IANA considerations requested with this document
Polk Page 14
Internet Draft MLPP over IP in SIP Feb 24th, 2003
7.0 Security Considerations
This topic is chalk full of security concerns. However, this document is
not requesting capabilities that are to be implemented on the open
Internet. The intention for SIP to extend itself to meet these
requirements is for interoperation and transition with existing closed
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
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 build infrastructures with these capabilities should not
influence the Internet or stray SIP Proxies that process non-MLPP over IP
transactions.
Certain domains will likely mandate that all UAs conform to this
functionality in order to communicate, with appropriate challenges
configured at each SIP entity to prevent unwanted or disallowed SIP
communications.
8.0 Acknowledgements
Your name here
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 specification ANSI T1.619-1992.
[3] ANSI specification ANSI T1.619A-1994.
[4] "Generic Switching Center Requirements" (GSCR), JIEO Technical
Report 8249, March 1997
[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.
Polk Page 15
Internet Draft MLPP over IP in SIP Feb 24th, 2003
[7] ITU-T Recommendation Q.735.3 (1993), "Description for Community
of Interest Supplementary Services using SS7 - Multilevel 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"
[10] ANSI T1.604-1990 "ISDN û Layer 3 Signaling Specification for
Circuit-Switched Bearer service for Digital Subscriber System
Number 1 (DSS1)"
[11] ANSI T1.610-1990 "DSS1 û Generic Procedures for the Control of
ISDN Supplementary Services"
[12] ITU-T Recommendation I.255.3 (1990), "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
"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
Polk Page 16
Internet Draft MLPP over IP in SIP Feb 24th, 2003
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
The Expiration date for this Internet Draft is:
August 24th, 2003
Polk Page 17
| PAFTECH AB 2003-2026 | 2026-04-22 13:47:50 |