Internet Engineering Task Force Internet Draft James M. Polk Expiration: August 23rd, 2001 Cisco Systems File: draft-polk-mlpp-over-ip-00.txt Multi-Level Precedence and Preemption over IP February 23rd, 2001 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-mlpp-over-ip-00.txt Page 1 Internet Draft MLPP over IP Feb 23rd, 2001 Abstract This document describes how the ANSI specification T1.619- 1992[1] and its extension T1.619a-1994 [2] should be mapped or correlated or migrated over to either a mixed TDM and IP network (with Gateways in between) or a pure IP network that requires the functionality of these two specs as Standard Operating Procedure. Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Table of Contents . . . . . . . . . . . . . . . . . . . . . 2 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 2.0 MLPP Overview . . . . . . . . . . . . . . . . . . . . . 4 3.0 Requirements for MLPP in an IP Infrastructure . . . . . 8 3.1 General Priority Requirements . . . . . . . . . . . . . 9 3.2 General Preemption Requirements . . . . . . . . . . . . 10 3.3 End Station Requirements . . . . . . . . . . . . . . . . 11 3.4 End user Requirements . . . . . . . . . . . . . . . . . 11 3.5 Internetworking Device Requirements . . . . . . . . . . 12 3.6 Media Gateway (MG) Requirements . . . . . . . . . . . . 12 3.7 General Security Requirements . . . . . . . . . . . . . 13 4.0 IP Infrastructure . . . . . . . . . . . . . . . . . . . 13 5.0 IANA Considerations . . . . . . . . . . . . . . . . . . 15 6.0 Security Considerations. . . . . . . . . . . . . . . . . 15 7.0 References . . . . . . . . . . . . . . . . . . . . . . . 16 8.0 Author Information . . . . . . . . . . . . . . . . . . . 16 1.0 Introduction This document describes how the ANSI specification T1.619- 1992[1] and its extension T1.619a-1994[2] should be mapped or correlated or migrated over to either a mixed TDM and IP network (with Gateways in between) or a pure IP network that requires the functionality of these two ANSI specs as Standard Operating Procedure within the IP portion of a network. T1.619-1992 describes an ISDN based ability of marking and tracking each and every (TDM) phone call, from call set-up, to connection, to completion (hang-up) throughout a defined Voice Network. I believe ISDN was originally chosen because of the D- Channel(s) and its control over associated bearer channels (usually 1 D-Channel controls 23 bearer channels in a PRI T1 circuit, but can and is take down to the BRI circuit (two B- Channels at 64kbps and one 16kbps D-Channel). In this marking Polk draft-polk-mlpp-over-ip-00.txt Page 2 Internet Draft MLPP over IP Feb 23rd, 2001 and tracking of every single phone call, the network becomes priority "aware" of which phone calls are important and which are not. Which phone calls have priority over others, and which do not. There are 5 levels of defined Priority given to every phone call. Under normal operating conditions of an T1.619-1992 enabled Voice network, no calls ever dropped, or prioritized greater than others that would cause anything to occur to those lessor Prioritized calls because there are no network bottlenecks, no congested interfaces, and no call flow problems. But this isn't always the case. Certain environments require the ability to prioritize calls over others in those network situations that bottlenecks occur and are deemed "important" phone call that need to get completed even if it means disconnecting an existing, pre-established call somewhere within the network. T1.619-1992 was written for networks that have this type of requirement. To have multiple levels of priority for all voice calls and the ability in the time of need, to preempt voice calls that are deemed less important than others in order to get those fewer, more important calls through the network to their intended destination. This specification has been called MLPP, for 'Multi-Level Precedence and Preemption' ever since its original publication in 1992. The Clarification document T1.619- 1994[2] merely clarifies some errors from the original specification and added some minor functionality, but didn't change the essence of the original specification. I am going to use the words 'Precedence' and 'Priority' inter- changeably throughout the remainder of this ID. Why is this document here needed in the IETF? Because these MLPP enabled networks were built. And they were sometimes built very big, by anyone's standards. One closed network I know of has 800+ Class 5's in it, for example; that's fairly large and fairly complicated, and it will be fairly difficult to migrate to our current love: Packets. IP packets to be more specific with our area of focus in the IETF. So, there needs to be a migration from an ISDN based, PBX based, TDM based Voice infrastructure to a partial ISDN/PBX/TDM based infrastructure and partial IP-based infrastructure, or just completely to an IP based infrastructure with MLPP capabilities. No functionality can be lost in this transition or build out. Polk draft-polk-mlpp-over-ip-00.txt Page 3 Internet Draft MLPP over IP Feb 23rd, 2001 Conventional wisdom sez that in order for consumers to move from one 'thing' or 'habit' to another, it requires some form of motivation to do that new 'thing' or 'habit'. In the telephony case, it's usually the case which this new idea costs a whole lot less (possibly with less functionality) or it has a whole lot more functionality (possibly costing more). But none of the consumers which are connected to MLPP enabled networks are paying a dime out of their own pockets for these networks, because they are utilizing this functionality only in their respective work environments. So, if cost isn't a factor (arguably), functionality is; an all-of-a-sudden-lack-in- functionality would and will be noticed and likely not positively. This document was written with another ID in mind that is intended to be a Standards track ID within the SIP WG [3] that is intended to be the smaller, SIP focused aspects of MLPP that needed extending within a WG that a "general" Informational- based ID could not stipulate or require. In other words, the intent here is to try not to solve MLPP in one BIG document. Where would it go, and who would oversee it? I decided to break it up into several ID's. This one is the larger overview, general ID, and Informational. In talking to Scott Bradner, he and I felt it wise to create this larger ID on an Info track, and submit the smaller Standards Track ID's into the appropriate WG's that had the need for adjustment or extensions for MLPP- specific features and capabilities. SIP was the first I identified and submitted into; there will likely be many others. I hope, as Scott does I believe, that each of these WG extensions will be small in nature and scope, tweaks if you will. MLPP is not the biggest thing to come to networking, and I don't want to treat it like it is. But there is a customer requirement (many actually) for these specific features and functionalities, and in talking with customers on both sides of the Atlantic, IP and voice communications will remain separated until these capabilities are incorporated into an IP-Manageable infrastructure in a Standards accepted way where multiple companies can provide products for bid. 2.0 MLPP Overview Multi level Precedence and Preemption Service Capability stipulates a relative priority ranking order of all Call flows on a hop-by-hop basis through a Voice Network from their relative beginning Voice device (calling party) to the end Voice device (called party). Within the TDM world, these Polk draft-polk-mlpp-over-ip-00.txt Page 4 Internet Draft MLPP over IP Feb 23rd, 2001 call flows were in a closed circuit switched network from a PBX or Tandem Switch to PBX or Tandem Switch. Each Switch, upon initiation of a higher priority call flow where there were no 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 switch determined overridden call. Typically, an audible tone occurred on the inbound caller's phone receiving the Preempting call flow. But this only occurred if that caller happened to be the resource that was preventing the higher priority call from being completed. In other words, like a forced call waiting with all the tones and such, but the existing call is not put on hold, it's disconnected. I don't know if that aspect of the MLPP spec is desired still or not, and should be looked at as a choice perhaps with a timer controlling how long the preempted call waits for the new call to be disconnected in order to reconnect the original call; with that first call being disconnected after an agreed upon timeframe within this spec. 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. 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. Also, every network device will need to have the code within it to make this Prioritization and Preemption determination similar or exactly like the Class 5's of today's MLPP networks, or there will be weaknesses in the IP Infrastructure that might prevent the proper completion of a (deemed) very important voice session. 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 Polk draft-polk-mlpp-over-ip-00.txt Page 5 Internet Draft MLPP over IP Feb 23rd, 2001 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 guarantees (in theory) that the most important commands (the President forbidding nuclear launch) would get through even over all other traffic of any priority or type. 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. 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" There are actually 16 values/levels possible within the ANSI spec, but any additional levels will have a preemption func- tionality 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 where network resources are already utilized. If these call values are equal, then other mechanisms, if any, can react according to their individual capabilities (e.g. Call waiting). One very important concept to keep in mind with anything here, is that if network bandwidth or resources or trunks have the Polk draft-polk-mlpp-over-ip-00.txt Page 6 Internet Draft MLPP over IP Feb 23rd, 2001 capacity to complete the call, it doesn't matter what the priority is of *any* call, each will get treated equally. Key concept: Unless resources are at their respective maximum somewhere in the network, the Priority level any call has doesn't matter in the least. 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 DSCP value[4]), 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 IP Voice device that is configured (somehow compliant with the parameters within that Administrative Domain (AD), and outside the scope of this document) to disable the ability to be preempted, that user or Polk draft-polk-mlpp-over-ip-00.txt Page 7 Internet Draft MLPP over IP Feb 23rd, 2001 IP Voice 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 [1]. 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 [1]. 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. 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. 3.0 Requirements for MLPP in an IP Infrastructure Since this is not currently a Working Group item from any WG in the IETF, this effort (right now) will not go through the process of a WG in the defining of Requirements first and attain consensus on those before proceeding. Hence, this section deals with the requirements of MLPP as I see them now. There could very well be more, that I am more than open to comment on this effort from my peers to that end, and possible inclusion in the next version of this I-D. Actually, this draft doesn't have a known home (email reflector) for discussion within the IETF either, and I'd like that to be solved by the London meeting. There has been some talk about placing this along with the IEPS efforts of Hal Folts [5] - and that's certainly possible. That is a worthy effort, and fairly similar in scope and architecture and complexity. And to make matter worse, I think it's questionable whether MLPP should *only* be written for Voice Communications over the long run. I see the great need to have it focus presently on Voice sessions (calls), but this should apply to anything that's RTP based at least, which is not just voice. And then in the future when authentication can be verifiable to a list of applications and Protocols within a IP-Managed network domain, to them as Polk draft-polk-mlpp-over-ip-00.txt Page 8 Internet Draft MLPP over IP Feb 23rd, 2001 well (but not yet). Therefore, I believe these requirements shall be written with Voice as an application in mind, discussions of this draft should also focus on what should be included, or removed, for other applications to take advantage of Priority and Preemption. I will simply put the requirements for MLPP over IP in bullet form for this version of the ID and categorize them into areas of scope or functionality. Keep in mind that these requirements must be adhered to by all devices within a single, IP-Managed Domain in order to function properly. 3.1 General Priority Requirements o 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" There are actually 16 values/levels possible within the ANSI spec, but any additional levels will have a preemption func- tionality below, or less than, "Routine". The intent is that "Flash Override" is always the highest level capable within a MLPP-compliant network. Where ANS.1/binary coding occurs, there must be 4 bits given to MLPP Prioritization as shown above where 0000 is the highest Priority level and 16 is the lowest. This doesn't match the TOS or Diffserv bit mapping, so this must be done somewhere else in the packet (of every packet). Where text coding occurs, the names associated with the 5 level of Priority must match the above order with "Flash Override" being the highest, and "Routine" being the lowest known one used. I acknowledge right now I'm not a coder, BTW. Polk draft-polk-mlpp-over-ip-00.txt Page 9 Internet Draft MLPP over IP Feb 23rd, 2001 o It is unclear if this infrastructure should apply to Instant messaging for Priority yet, but it likely will at some point 3.2 General Preemption Requirements o Any party whose connection was preempted (whether that resource was reused or not) shall receive a distinctive audible notification [1]. An addition notification can be provided via some visual indication if possible or desirable; o 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, o When there are no idle resources, preemption of the lowest of these lower level Precedence resources shall occur; o How to chose which established session, amongst the probable many that traverse an interface experiencing congestion, is to be terminated when a higher Priority session is initiated through an internetworking device is likely a topic needing discussion. I would vote for the session that has existed the longest through that interface, meaning per session timers must be kept either within the internetworking device (in COPS [6], the PEP) or the server/node making the policy decisions for that internetworking device (in COPS [6], the PDP, which could be co-located and is allowed for in that RFC) o If more than one session must be preempted in order to allow that new high priority session through a congested network interface, this must be allowed to occur on any inter- networking interface within this MLPP domain o Discussion is needed to determine if Voice (and possibly Video) session should be allowed to drown out or starve all other types of traffic through any congested network interface. The Diffserv WG had similar discussions and I don't know if an outcome was chosen. Conventional wisdom has Polk draft-polk-mlpp-over-ip-00.txt Page 10 Internet Draft MLPP over IP Feb 23rd, 2001 a limited amount of the bandwidth through any interface for any one application or Protocol, but that is absolutely choice for each domain. o It is unclear if this infrastructure should apply to Instant messaging for Preemption yet, but it likely will at some point 3.3 End Station Requirements This section includes the IP devices that start the MLPP-enabled communication (IP phones, PC's, Handheld's and the likeà) o Ability of the End Station to generate RTP sessions with all 5 MLPP Priority levels in the Packet headers, whether that's self signalled (like would be the case in SIP), or determined from another Node on the network (Server or Media Gateway Controller) for a defined Standard (MEGACO [7]) or Proprietary Control Protocol; I don't know if the initial Priority level should be set to "Routine" for all users and have them individually raise the level within what they are authorized to set to if they need to, or if this aspect is more network controlled on logon and authentication to the network, and that user's profile within that domain controls each, or at least the default Priority level. Discussion on this should occur to reach consensus. o Ability to differentiate users and allow each user's access only to those priority levels they are authorized to initiate per session (in the current MLPP-ISDN networks, the level of Priority is determined by, and only by, the color of the phone; which is hardwired to a PBX interface that is configured at a certain single MLPP Prioritization level) o The Preemption audible tone and generator stipulated in [1] must be built/written into each end station 3.4 End user Requirements This section includes the people themselves that are placing the Voice (and possibly Video) call sessions for now, but will likely include the automated initiation of sessions by non- humanoids soon ;-) But this could fall under whether IM Polk draft-polk-mlpp-over-ip-00.txt Page 11 Internet Draft MLPP over IP Feb 23rd, 2001 receives this applicability of MLPP. o Ability to uniquely identify themselves to the MLPP enabled network in order to be granted the priority choices (this quickly gets into the Security aspects discussed below) 3.5 Internetworking Device Requirements This section includes Layer 2 & 3 switches, Routers and Servers: o Monitor all interfaces within each internetworking device for congestion and resource allocation o Appropriately self regulate all congestion interfaces similar to COPS configurations [6] in which a individual internetworking device makes decisions either locally (it is both the PEP and PDP for a scenario or as a rule within that network), to utilizes the COPS Protocol for communication with a COPS Server for specific traffic instructions down to the session level o When an MLPP session preempts another MLPP session on an internetworking device, and that internetworking device is not directly attached to any of the 3 or 4 end users of either session, it must signal the end stations that were preempted notifying them of the occurrence(I'm not sure what Protocol should be used here, but SNMP could be utilized even if authentication is necessary, although its modification might be necessary via an ID) 3.6 Media Gateway (MG) Requirements This section includes Media Gateways that are not end stations within the MLPP infrastructure, but translate either from IP to some TDM infrastructure (ISDN could mean another MLPP network, PSTN TDN means from a non-MLPP network): o If the MG is connected between an IP-based MLPP network and a non-MLPP network, it must set the Priority to "Routine" for that incoming call (unless someone clever creates a way for that user to uniquely identify themselves to an IP-MLPP device and allows the session to receive higher Priority; comments here are again welcome) Polk draft-polk-mlpp-over-ip-00.txt Page 12 Internet Draft MLPP over IP Feb 23rd, 2001 o If the MG is connected to a known and trusted MLPP-enabled network (in either direction and determination which is outside of the current scope of this document), let the Priority of the calling party continue (unless your network has a policy to do something different with the incoming call request, of course) An example of this case is the transition of an MLPP enabled ISDN network to that of an MLPP enabled IP network. With these existing networks being the size they are, there will be a mi- gration from one infrastructure type to the other, maybe not completely getting ride of the ISDN network for quite some time, if ever. There are several other examples of MG networking scenarios, but I won't list them all here just yet. Suffice to say, the MG is either in your network from the IP network to an ISDN network (which may or may not be MLPP enabled) or PSTN point of view, and is either connected to a trusted side and an untrusted side (as is likely the case in connection to any network not MLPP enabled), or both sides are trusted either in a transition mode, or through an SLA interconnection. Updated versions of this ID can have any example of infrastructures interconnectivity for simplicity or as a more firm example if necessary. 3.7 General Security Requirements o This is an somewhat ambiguous requirement for the authentication and authorization of all End users, this is likely network specific to some external form of authentication such as a SmartCard for the *trusted* identification of each authorized user, granting them access to resources as well as MLPP Priority levels for call sessions 4.0 IP Infrastructure Obviously, if [1] is to be adhered to but in an IP infra- structure, and even in a transitionary network (one that is migrating from ISDN enabled to IP enabled MLPP), a lot of aspects of how RTP sessions (principally Voice) over IP will require sometimes significant changes in how networks are currently configured. Some of these changes will require Standards to be modified and new code to be written from those Standards into some or most of existing network devices in order to follow [1] to the letter. Polk draft-polk-mlpp-over-ip-00.txt Page 13 Internet Draft MLPP over IP Feb 23rd, 2001 Customers that I've talked to have not been willing (so far) to give away any functionality from [1] within their networks. It gets more complicated where GETS requirements are included from [5], because that involves theoretically every phone and phone line in the US; but that's for another ID to deal with. Below is a list of topics that need discussing in order to change/ modify/extend/enhance existing IETF Specifications to enable MLPP in IP networks. I believe this list will get longer with time and discussion and more detailed in nature. o Within the IETF for Signaling Protocols and Media Gateway Control Protocols, SIP & MEGACO are affected by this effort. Each will have to (for the strict MLPP compliance) modify their respective headers to include the 5 levels stipulated in 3.1 o RSVP [8] is not mandatory for MLPP, but it is the only bandwidth aware IP Protocol within the IETF that can handle RTP streams that I'm aware of. Without this virtual session created by RSVP, I'm at a loss now as to how any inter- networking device will be able to differentiate one RTP session from another, making Preemption virtually impossible. Therefore, I believe RSVP o COPS apparently isn't aware of both endpoints of an RTP session, so it for signaling or even making aware of a Preemption occurrence is not yet likely possible Problem with SIP in [9] and the bis draft [10] is that they modified in the bis draft to go to 5 levels from 4, but the 5th level was placed at "less than normal", and doesn't coincide with the MLPP 5 levels. This might not be a big deal to a lot people, but people running MLPP network mandate the existing 5 levels defined in [1]. This is part of what [3] covers, along with a additional Header-Field "MLPP Enabled", it provides the 5 MLPP levels due to this inconsistency between the two requirements. This also relieves the SIP WG for making the main effort of that WG responsible for complete incorporation of MLPP into every SIP based product (at this point). I'm trying not to disrupt WG's as much as possible. This section should and will have more substance to it in the next version of this I-D. But due to time constraints and an Polk draft-polk-mlpp-over-ip-00.txt Page 14 Internet Draft MLPP over IP Feb 23rd, 2001 unforeseen event, this -00 version wasn't as fulfilling as it shall be in the near future. Comments will also (hopefully) substantially add and clarify this I-D as it progresses. 5.0 IANA Considerations This author doesn't believe there are any within this document at this time. 6.0 Security Considerations A wise person said once (OK, it was Dave Oran, one of our AD's, and I'm paraphrasing): "End user Security for real time sessions never was that important until the effective use of QoS (priori- tization) could be realized". This effort is stipulating that exactly that scenario and Architecture can be and is built in the Packet world. All arguments with whether Dave's statement is exactly correct aside, I believe there is a great amount of truth to this in concept. Every session between anyone can have all the prioritization anyone wants, but until there is an effective way to preempt another's session, it's meaningless. But on the other hand, imagine (at least in the US) you have the ability to set your voice call into Ticketmaster to get priority treatment for all concert and sporting events tickets? Very few would notice they had been the one's to have their calls dropped while waiting on hold, but it would still be a unfair treatment of network traffic loads and unfair to the person you just preempted. This creates the need for some form of user authentication and authorization. I don't think the major IP carriers are going to evoke or enable MLPP in their networks, but anywhere there is Priority and the possibility of Preemption, there needs to be some checks and balances. On those closed boundary networks that enable this feature(s), authentication and authorization is required in my opinion; unless, that network is perfectly traffic engineered and there can never be a situation where network resources can bottleneck in any way. Because, when enabled, even a single interface that has too little resources can and likely will experience this Preemption on that interface. Polk draft-polk-mlpp-over-ip-00.txt Page 15 Internet Draft MLPP over IP Feb 23rd, 2001 7.0 References [1] ANSI specification ANSI T1.619-1992. [2] ANSI specification ANSI T1.619A-1994. [3] James M. Polk, "draft-polk-sip-mlpp-mapping-01.txt", IETF Internet Draft, February 2001 [4] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB" RFC 2598, June 1999 [5] H. Folts, H. Ohno, "draft-folts-ohno-ieps-considerations- 00.txt" IETF Internet Draft, June 2000 [6] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 2748 January 2000 [7] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers, "Megaco Protocol Version 1.0", Request for Comments: 3015, November 2000 [8] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [9] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "SIP: Session Initiation Protocol" RFC 2543, March 1999 [10] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "draft-ietf-sip-rfc2543bis-02" IETF Internet Draft November 24, 2000 8.0 Author Information James M. Polk Cisco Systems 18581 N. Dallas Parkway, Suite 100 Dallas, TX 75287 jmpolk@cisco.com Polk draft-polk-mlpp-over-ip-00.txt Page 16 Internet Draft MLPP over IP Feb 23rd, 2001 "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 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: August 23rd, 2001 Polk draft-polk-mlpp-over-ip-00.txt Page 17