Internet Draft James M. Polk Expiration: September 2, 2001 Cisco Systems File: draft-polk-sip-mlpp-mapping-01.txt SIP Extension for MLPP March 1, 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-sip-mlpp-mapping-01.txt Page 1 Internet Draft SIP Extension for MLPP March 2001 Abstract This document describes an extension to the Session Initiation Protocol [1] to allow SIP (and IP) into existing Voice Backbone Infrastructures that require Multi-Level Precedence and Pre- emption [2] Service throughout those networks. This document will also allow MLPP networks that are ISDN-based now to evolve/ migrate or be replaced by a SIP-based Voice Signaling network with no loss in capability of that original network. More likely is the case that additional functionality and capabilities can be realized such as mobility and reduced user headaches (ex- plained later) with SIP being MLPP enabled within a network infrastructure. I believe these additional Precedence and Preemption capabili- ties will have wider deployment benefits than named MLPP networks such as the US Government networks. Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Table of Contents. . . . . . . . . . . . . . . . . . . . . . 2 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . 3 2.0 The need for this Extension vs. incorporation? . . . . . 3 2.1 Part of a bigger effort? . . . . . . . . . . . . . . . . 4 3.0 MLPP Overview. . . . . . . . . . . . . . . . . . . . . . 5 4.0 Objective of ANSI's MLPP specification . . . . . . . . . 6 5.0 Requisites from ANSI's MLPP Specification. . . . . . . . 7 6.0 Defined SIP Priority request-header field. . . . . . . . 9 7.0 Request Header-Field:MLPP-Enabled Extension . . . . . .10 7.1 A subset of MLPP? . . . . . . . . . . . . . . . . . . .11 8.0 Results of MLPP Extensions to SIP Priority Field . . . .11 9.0 Unknowns needing discussion still . . . . . . . . . . .13 9.0 Changes from the last version . . . . . . . . . . . . .14 10.0 IANA Considerations . . . . . . . . . . . . . . . . . .14 11.0 Security Considerations. . . . . . . . . . . . . . . . .14 12.0 References. . . . . . . . . . . . . . . . . . . . . . . 15 13.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . 15 14.0 Author Information. . . . . . . . . . . . . . . . . . . 16 Polk draft-polk-sip-mlpp-mapping-01.txt Page 2 Internet Draft SIP Extension for MLPP March 2001 1.0 Introduction This document describes an extension to the Session Initiation Protocol [1] to allow SIP (and IP) into existing Voice Backbone Infrastructures that require Multi-Level Precedence and Pre- emption [2] Service throughout those networks. This document will also allow MLPP networks that are ISDN-based now to evolve/ migrate or be replaced by a SIP-based Voice Signaling network with no loss in capability of that original network. More likely is the case that additional functionality and capabilities can be realized such as mobility and reduced user headaches (ex- plained later) with SIP being MLPP enabled within a network infrastructure. I believe these additional Precedence and Preemption capabili- ties will have wider deployment benefits than named MLPP net- works such as the US Government networks. 2.0 The need for this Extension vs. incorporation? As much as I believe this in this capability, I also believe it should be necessarily a burden for all SIP developers to include. Therefore, I believe this I-D should be a Standards Track WG item, but separate for the core 2543bis effort such that those vendors that wish to develop products into this fairly limited, yet potentially very large segment, can merely be following this I-D. I believe this will also help in the IETF Standarding process of SIP by itself by not being included in the core effort mandating (I believe) 3 completely interoperable solu- tions for every feature and specification within the SIP I-D. An additional reason for this maintaining its name is the customer driven requirement and comfort-zone of MLPP itself. An RFP can state fairly clearly that it requires adherence to RFC-XXXX (SIP Ext. for MLPP) in its bidding between vendors. This does make it quite a bit easier for that process as well. I'm also aware of the desire to NOT include everything and the kitchen sink in the core 2543bis effort. SIP is, and is well put in [3], "not a PSTN replacement". And any Priority or Preemption without government intervention is not allowed (GETS [4] is the best example of this). "SIP is a Protocol for initiating, modifying, and terminating interactive Polk draft-polk-sip-mlpp-mapping-01.txt Page 3 Internet Draft SIP Extension for MLPP March 2001 sessions" from [3] as well. Which goes on to state the following that applies directly: " This process involves the discovery of users, (or more generally, entities that can be communicated with, including services, such as VM or translation devices) wherever they may be located, so that a description of the session can be delivered to the user." Sometimes the Signaling for a session will take the same path the RTP stream will, most times it will not. Although each will likely take different paths, the specifics of the MLPP call set-up such as which Precedence level is chosen by the user needs to start with the calling or session initiating device. Even though SIP is intended to traverse more than a single network infrastructure in its creation, MLPP functionality like- ly will not, but could on a limited basis where strict SLA's or similar agreements are adhered to. Creating an Extension that is basically intended for a single network is generally frowned upon, and I understand. Additionally, extensions that define a function's usefulness only if all devices support that extension is also discouraged [3]. However, one of the networks that requires MLPP adherence before considering IP-based anything voice session initiation has currently more than 800 Class 5's operating in that network. The migration to IP will difficult at best for this one network that has such strict requirements, and that is the reason for this Extension: adherence to strict guidelines and capabilities in a "Standards way". I have talked to a customer representing parts, to all of 19 country's government networks that are mostly all waiting on MLPP to be defined in IP in this Standarding Body before moving their respective networks towards IP. So, the question that I pose to you is this I-D: 2.1 Part of a bigger effort? Yes, this I-D is part of a larger IETF effort. I have written an I-D [5] that attempts to address the non-SIP requirements for enabling MLPP into an IP network infrastructure. What I propose here is just what SIP is intended to do: initiate the session with certain features, capabilities and descriptions in that session initiation. Relatively speaking, this is easier than getting the network to behave in a deterministically Preemptive mode to a customer's satisfaction. It gets more complicated with Polk draft-polk-sip-mlpp-mapping-01.txt Page 4 Internet Draft SIP Extension for MLPP March 2001 inclusion of 'other' services. IM could become MLPP-enabled. Video certainly could, but traffic engineering then becomes a problem due to its bandwidth requirements. Another effort was started at the Pittsburgh meeting, IEPS [4]. It has been suggested that this MLPP effort is the logical pre- cursor to the IEPS effort. Section 1.2.1 of [4] refers to another type of PSTN requirement, GETS (Government Emergency Telephone Service). MLPP could be used as a basis for that requirement with some user authentication enhancements. 3.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 "Header-Field:Priority" as a non-mandatory field within the signaling set-up (section 6.0 shows this). The 2543bis I-D [7] added a single Priority Header-Field that is and for less than normal traffic. Although this creates 5 distinct Priority levels, it does not satisfy the MLPP semantics require- ments of 5 levels with normal traffic (called 'Routine' by [2]) at the lowest Priority or Precedence level, escalating to the highest Priority or Precedence level (called ' Flash Override' in [2]). All this is explained in more detail on the next page in section 4.0. Polk draft-polk-sip-mlpp-mapping-01.txt Page 5 Internet Draft SIP Extension for MLPP March 2001 4.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 PRI- ORITY 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 relative importance to a session is how an authorized user can assign the appropriate priority to traffic based on that user's Profile (e.g. within what they are auth- orized to assign a session to). 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. Polk draft-polk-sip-mlpp-mapping-01.txt Page 6 Internet Draft SIP Extension for MLPP March 2001 5.0 Requisites from ANSI's MLPP Specification 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 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: Polk draft-polk-sip-mlpp-mapping-01.txt Page 7 Internet Draft SIP Extension for MLPP March 2001 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. Here coordination with a Bandwidth aware mechanism such as RSVP will be needed, making sure that the Preempting call is assigned that bandwidth freed up from the call clearing action. 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 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]. Section 8.0 of this I-D discusses the potential rele- vance of this feature. An alternative to this approach could be to have an 'alternate called party' signaled (e.g. that person's administrator). 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 Polk draft-polk-sip-mlpp-mapping-01.txt Page 8 Internet Draft SIP Extension for MLPP March 2001 lowest precedence level by default until the user chooses a level up to 'their' maximum authorized within that Domain. Controlling whether users always chose the lowest level, or the Appropriate level, is an administrative decision, and outside of the scope of this document. 6.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 [8], with the addition of "emergency". " In the 2543bis draft [7], this has changed to include a 5th Priority value "other priority" (section 6.31 of [7]), but doesn't change the semantics of this section otherwise; meaning "emergency" is still the recommendation for highest Priority, but only in the case of an *emergency* (pun partially intended). The next level with less Priority is "urgent", which is followed by the Priority value that might as well be the default Priority value of most SIP messages, because this is the value for "normal" traffic - where most voice sessions will take place. Whatever the "non-urgent" value is supposed to provide other than less than "normal", it doesn't match the MLPP model at this end of the spectrum as well as not having multiple "emergency" levels similar to MLPP ("Flash" and "Flash Override"). Polk draft-polk-sip-mlpp-mapping-01.txt Page 9 Internet Draft SIP Extension for MLPP March 2001 Even if "non-urgent" were mapped to everyday session traffic, the Priority model of [3&7] won't match enough, and a separate Header-Field is necessary Both [3 & 7] state this Header-Field is not necessary, it fact it Has been mentioned at numerous meetings that this header-Field isn't even used, so why all the fuss about MLPP. 7.0 Request Header-Field:MLPP-Enabled Extension The MLPP-Enabled request-header field indicates the relative Pri- ority of the session initiation as perceived by the client. MLPP-Enabled = "MLPP-Enabled" ":" MLPP-priority-value MLPP-priority-value = "Flash Override" | "Flash" | "immediate" | "Priority" | "Routine" The semantics are a repeat of the Military example from section 3.0: 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 PRI- ORITY 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 relative importance to a session is how an authorized user can assign the appropriate priority to traffic Polk draft-polk-sip-mlpp-mapping-01.txt Page 10 Internet Draft SIP Extension for MLPP March 2001 based on that user's Profile (e.g. within what they are auth- orized to assign a session to). 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. 7.1 A subset of MLPP? A subset of MLPP can also be implemented not having all 5 levels of Precedence, and still be quite useful in infrastructures desiring the explicit benefits of the semantics stated above, yet don't implement all 5 levels from a case of need. Examples can easily be seen in Hospitals under emergency situa- tions like power outages or "Code Blues" where a patient's heart has stopped and the IP infrastructure requires an explicit mecha- nism in place to ensure Prioritized traffic reaches its destina- tions in the time expected. Another example is where this relative Prioritization of certain types of traffic (here SIP initiated) are constantly provided the higher levels regardless of the state of the network con- gestion levels at any time. Financial Institutions where stock trading occurs and can't "get a busy signal". 8.0 Results of MLPP-Enabled Extension to SIP 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 (at first) have the need for Precedence classification within a Domain's control. This is the purpose of this request for Extension to the SIP Protocol, and the reason I believe this should be a separate effort, not tied to the main SIP effort. I realize this isn't to be implemented everywhere (too tight or focused a specification) and desire the vendors and customers to look at this specifi- cation separately for implementation purposed both in products to be built, and features to be incorporated: * SIP end-device MUST include the Request Header-Field "MLPP-Enabled:" in all session signaling, regardless of the session's intent or destination; Polk draft-polk-sip-mlpp-mapping-01.txt Page 11 Internet Draft SIP Extension for MLPP March 2001 * Header-Field " MLPP-Enabled:" MUST be default set to 'Routine' unless the calling party specifies an author- ized Higher Value for all call sessions; * User must be authorized to access higher Priority values for any Higher Precedence session initiations (method of authorization is outside the scope of this document) in order to utilize those higher levels; * 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: * 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 a fast busy * SIP-based Gateways within MLPP-enabled Domain MUST have direct mapping of ISDN Signaling according to [2 and 9], else they should merely create the SIP Header with the request Header-Field MLPP-Enabled, while entering a Pre- dence value of "Routine" for that session; * It is believed COPS should be utilized for mid-session path rejections due to congestion (of what [2] calls "call clearing", when a Higher Precedence 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; Polk draft-polk-sip-mlpp-mapping-01.txt Page 12 Internet Draft SIP Extension for MLPP March 2001 9.0 Unknowns needing discussion still There are many unknowns still regarding the migration of the original ANSI requirements in [2] into a SIP implementation here. Discussion would be greatly encouraged on at least these issues listed below to determine from the original requirements for having something like MLPP, how much of those requirements need to evolve for today's (and the future's) capabilities in networking. Here is a brief list of a few of them: o Conferencing - if a caller is on the conference bridge, for example, and a call clear event occurs (meaning they are the recipient of the inbound higher priority call) does every- one need to hear the audible tone? If a caller is on a conference bridge, and they are preempted by a network resource bottleneck that causes their respective leg to terminate, does everyone hear the audible tone Should there be some provision for announcing to the conference 'who' has been terminated from the call (where possible by some other mechanism)? o Version ID - Currently [7] defines as mandatory the SIP version number or value be included (section 4.3.1 of [7] to be specific). I don't know yet how to identify this cap- ability of MLPP in the SIP headers. I don't know in a 'letter' should be added to the SIP/2.0? I'm at a loss right now on how to solve this and am looking for suggestions. o Speaker - The part of the ANSI spec [2] which states that if the called party who is still in a session has to acknowledge the higher pri- ority in-bound session and answer it, else have their respective device's speaker turned on (in the case of that user merely hanging up or terminating the session to avoid answering or acknowledgement of this Polk draft-polk-sip-mlpp-mapping-01.txt Page 13 Internet Draft SIP Extension for MLPP March 2001 new session). This feature might not be desired further, but there should dis- cussion from those that have experience with MLPP to see if this is the case. 9.0 Changes since the Last Version The following is a list of the noticeable changes to this effort from the -00 version of this I-D: o Changed the name and scope of this draft to "SIP Extension for MLPP" requesting that a separate Request Header-Field: MLPP-Enabled be created in this draft on a Standards Track apart from the main SIP effort due it limited focus, yet usefulness within certain markets o Hinted at the potential synergies with both IEPS and GETS efforts o Suggested the use of a sub-set of the MLPP effort outside the strict environments that still require all of MLPP's features like Hospitals and Financial Institutions o Added section 9.0 "Unknowns" to this version to attempt to bring out the known differences in the why in which Voice networks operated 'then' verses now and in the near future; 10.0 IANA Considerations This author doesn't believe there are any within this document. 11.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 Polk draft-polk-sip-mlpp-mapping-01.txt Page 14 Internet Draft SIP Extension for MLPP March 2001 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. 12.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] J. Rosenberg, H. Schulzrinne "draft-ietf-sip-guidelines-01" IETF Internet Draft, November 2001 [4] K. Carlberg, "draft-carlberg-ieps-framework-00", Internet Draft, November 2000 [5] James M. Polk, IETF Internet Draft "draft-polk-mlpp-over-ip", March 2001 [6] 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) [7] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "draft-ietf-sip-rfc2543bis-02" IETF Internet Draft, November 24, 2000 [8] Palme, J., "Common Internet message headers", RFC 2076, February 1997. [9] ANSI specification ANSI T1.619A-1994. 11.0 Acknowledgments I'd like to thank Scott Bradner for his advice on this effort and all of this MLPP efforts direction within the IETF up to this point. Polk draft-polk-sip-mlpp-mapping-01.txt Page 15 Internet Draft SIP Extension for MLPP March 2001 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 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 2, 2001 Polk draft-polk-sip-mlpp-mapping-01.txt Page 16