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