Internet Engineering Task Force Internet Draft James M. Polk Expiration: May 22nd, 2002 Cisco Systems File: draft-polk-mlpp-over-ip-01.txt An Architecture for Multi-Level Precedence and Preemption over IP November 21st, 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 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. 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-01.txt Page 1 Internet Draft MLPP over IP Nov 21st, 2001 Abstract Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 Definitions and Conventions . . . . . . . . . . . . . . . . . . 4 3.0 Motivation for replicating functionality into IP Networks . . . 8 4.0 MLPP Requirements in any Network . . . . . . . . . . . . . . . 8 4.1 MLPP Precedence. . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 MLPP Preemption. . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1 Access Preemption Event . . . . . . . . . . . . . . . . . . . . 11 4.2.2 Network Preemption Event . . . . . . . . . . . . . . . . . . . . 12 4.3 MLPP Feature Scenarios . . . . . . . . . . . . . . . . . . . . 12 4.3.1 Bearer Services Supported . . . . . . . . . . . . . . . . . . . 12 4.3.2 Commonalities of Interest . . . . . . . . . . . . . . . . . . . 13 4.3.3 Conferences Preset . . . . . . . . . . . . . . . . . . . . . . 13 5.0 MoIP Requirements and solutions . . . . . . . . . . . . . . . . 13 5.1 Setting Priority to an MoIP Session . . . . . . . . . . . . . . 14 5.2 SDP in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3 SIP in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4 MEGACO in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.5 MGCP for MoIP . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.6 Differentiated Services in MoIP . . . . . . . . . . . . . . . . 18 5.7 RSVP in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.8 NSIS in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.9 MPLS in MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.10 RTP for MoIP . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.11 Gateway Requirements Regardless of Protocol . . . . . . . . . . 20 6.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 7.0 Security Considerations . . . . . . . . . . . . . . . . . . . . 21 8.0 Changes since last version . . . . . . . . . . . . . . . . . . 21 9.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 10.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.0 Author Information . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.0 Introduction The intent of this document is to introduce an Architecture for Multi- Level Precedence and Preemption (MLPP) into the IP realm. MLPP was originally written to create "a prioritized call handling service" [1] in combination with ISDN supplementary services. MLPP has two very simple concepts for voice (Real-Time) communications: Polk draft-polk-mlpp-over-ip-01.txt Page 2 Internet Draft MLPP over IP Nov 21st, 2001 A) setting or marking every session at inception with a Precedence level relative to others within a known network domain; and B) the end-stations or internetworking devices preempting lower relative priority sessions in order for higher relative level sessions to pass or occur during times of congestion at any point in that known, managed domain, including to the end-station (phone). This concept has existed for more than a decade, and been deployed in many networks throughout the world for years. It is based, or founded, in US Government network requirements. It is an augmentation service to ANSI's ISDN [21,22,23,24]. This document is the first attempt, though incomplete at this time, at bringing those specialized functionalities of MLPP from a more traditional world voice communications delivery practice into the IP realm. MLPP over IP, or MoIP, shall specific as many IETF Standards and practices as possible. The intend here is not to reinvent anything that already exists. However, certain functionalities in IETF Protocols will require adjusting, or extending, to fit the MLPP model that will be laid out within this document to satisfy the requirements and experiences of the trained user of MLPP in the past. Most of the specifications and concepts stated here for MLPP were taken from the ANSI specification T1.619-1992 [1] and its supplement T1.619A- 1994 [2]. Still other specifications and concepts stated here are from ITU Q.735.3 [19]. Any remaining details and concepts attained from documents came from the certification materials which all products must tested against to achieve MLPP compliance and interoperability status [17,18]. There are a few concepts mentioned here that were attained from inter- viewing 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 state its scope, to include what will and will not be covered here. It will define all the terms as best as possible due the readers might not be completely familiar or savvy with the IETF and its languages, but from more of a telephony background where MLPP lives today. This document will then define the network feature and functions necessary to be compliant with existing MLPP networks. This is as much a background and education, or level-setting, as anything. This section will detail the known behaviors each component of an MLPP network must do under explained circumstances and scenarios. The next section will get into the IP realm of MoIP. Please notice the convention change. Within this document, MLPP shall refer to the tra- ditional GSTN-based MLPP network and all components and requirements; whereas, MoIP shall refer to its IP based counterpart. That Counterpart shall be near in functionality, but this isn't exactly an apples to apples conversion from one topology to another. Some things will change. Some functionality will be done a different way, some will be enhanced, and some functionality will not exactly be replicated. The circuit switched Polk draft-polk-mlpp-over-ip-01.txt Page 3 Internet Draft MLPP over IP Nov 21st, 2001 world has some advantages, such as maintaining state of a circuit end-to- end, that IP doesn't have easily. As best as possible, the document shall point out where a functionality is enhanced, duplicated, or how far replication falls short. Next there will be an IANA Considerations section to the IANA group for registration of mappings, which shouldn't occur here as this is not a Standards Track document. This section will be followed by the security considerations section which states all the security problems enacting this document should cause. No normative language should be within this section, but here there shall be the remaining caveats not previously covered within this document, with some reminders, but more general language here. The details are within the document's main text in previous sections. The next 4 sections are: Acknowledgements, the changes since the last version of document, the references and author's information sections. After the main body of this document, following the author section, are the Appendices, which are empty in this version. These are of importance as they shall contain the examples sections of network topologies with certain functionalities present, and others not present, and the details of how the basic MLPP requirements are met within the MoIP part of that topology. There shall be a different Appendix for each topology and set of protocols present. Within each Appendix, the rules stay the same for each MLPP requirement to be explained. There could potentially be an endless number of Appendices, but the most popular, or most predictable present set of topologies are detailed out here. As this document progresses, I expect more and more examples, or Appendices, to be written, and discus- sion occurs regarding this document, and IÆm reminded how certain 'impor- tant' environments were left out, and but should be included and explained within this document to be considered more complete. 2.0 Definitions and Conventions 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 Assured Forwarding AF [13] in Diffserv û marks the IP Headers with a codepoint value relating to the expected behavior of that value throughout a single IP domain on a per hop basis DE MLPP defined as the PBX the destination endstation is directly connected to Polk draft-polk-mlpp-over-ip-01.txt Page 4 Internet Draft MLPP over IP Nov 21st, 2001 Diffserv Differentiated Services [3] û IETF Standard defining a Priority marking of IP Packets to achieve deter- ministic behavior through an IP-based network Domain For MLPP, the set of MLPP subscribers and contiguous network resources in use at any time supporting those MLPP subscribers; For IP, everything within the logical IP boundary supporting MoIP capabilities in a single network Edge Router ER - A Router at the logical boundary of an MoIP Domain End Office Node EN û see EOS End Office Switch EOS û Similar to a 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 Endpoint H.323-based voice device (IP Phone) utilizing only H.323 Signaling Protocols Expedited Forwarding EF marking [12] in Diffserv creating a forwarding queue with no other above it, that in which a packet entering the queue shall not be delayed by more than one packet length/time from any other queue 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 Switched Telephony Network û worldwide circuit switched public telephony network H.323 ITU originated Peer-to-Peer Multimedia Signaling Protocol ISDN Integrated Services Data Network Label Switched Path LSP û MPLS short fixed length label assigned to packets upon ingress to an MPLS cloud. This label is what MPLS Routers use to make forwarding decisions on. Look ahead For Busy LFB û this optional feature has one endstation prematurely acquiring the path, preempting if necessary, to another endstation; this can occur any interval before the call/session is actually placed Media Gateway See Gateway above û but one side is IP, and the is not; could be analog voice of an IP phone, or it could be a trunk interface to a PBX Polk draft-polk-mlpp-over-ip-01.txt Page 5 Internet Draft MLPP over IP Nov 21st, 2001 Media Gateway Controller MGC û or Call Agent û the server that acts as the control plane for audio, video, or both, or full multimedia communications MGCP Media Gateway Control Protocol û IETF Informational RFC 2705 Client/Server based Call Control Protocol of media Gateways (Gateways or IP Phones), resulted from the merger of IPDC and SGCP MLPP Multi-level Precedence and Preemption [1 & 2] û ANSI T1.619 and 619A specifications stipulating mechanisms for marking each voice communication with a Prece- dence level, and defining the requirement for the Preemption of lower Precedence existing sessions during congestion in favor of new higher Precedence sessions MoIP MLPP over IP MPLS Multi Protocol Label Switching [4] û IETF Standard for using label switching and for the implementation of label-switched paths over various link-level tech- nologies, such as Packet-over-Sonet, Frame Relay, ATM, and LAN technologies Multifunction Switch MFS - A combination of a End Office Switch (EOS) and Tandem Switch (TS); having trunking and CPE connec- tion capabilities within one, more economical unit NSIS Next Steps in Switching û currently a proposed IETF Working Group to focus on simplifying signaling within a network vs. a more heavyweight version: RSVP OE MLPP defined as the PBX the originating endstation is directly connected to Precedence The relative priority level assigned to each session Precedence Call Any call that has a Precedence level higher than Routine Preempt Notification The notification sent from the endstation receiving the inbound preempting call to the endstation being preempted from their previous call/session Preempted The audible notification sent to all endstations who have been preempted for any reason Preempting Call Is 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 [6] that acts on behalf of other Devices Polk draft-polk-mlpp-over-ip-01.txt Page 6 Internet Draft MLPP over IP Nov 21st, 2001 Registrar Server SIP Server [6] 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 [1] 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 [1] as from 5 û 20 seconds RSVP Resource Reservation Protocol û IETF Standard defined in RFC 2205, for reserving bandwidth from end station to end station, without congestion affecting it once the path exists SLA Service Link Agreement û Agreement between two adja- cent networks on many aspects of how one's traffic gets treated within the other's network Switch Packet-based multiport Router intended for internal network use and not connected between different networks (owners); here they are Layer 3, or IP- Header, aware devices that switch packets to desti- nation interfaces based on the Destination address within a packet Tandem Switch TS - Only connects to EOS's; is the primary backbone of a circuit-switched MLPP Network Termination The end of a circuit, or in the MEGACO definition, the end device, a Gateway circuit or IP-based Phone Transit Router Router or any Layer 3 aware device that is not an endpoint in the communications path, but that path travels through it to get to the destination User Agent SIP [6] defined as an application which can act both as a user agent client and user agent server User Agent Client SIP [6] defined is a client application that initi- ates a SIP request User Agent Server SIP [6] defined A user agent server is a server Application that contacts the user when a SIP request is received and that returns a response on behalf of the user. The response accepts, rejects or redirects the request. Polk draft-polk-mlpp-over-ip-01.txt Page 7 Internet Draft MLPP over IP Nov 21st, 2001 VPN Virtual Private Network; defined as existing among many devices, but able to communicate with only a network pre-configured limited number of devices, at the same time, devices not belonging to this group within the private network cannot communicate within either 3.0 Motivation for replicating functionality into IP Networks Many MLPP-based networks wish to move into the IP realm, yet have opera- tional features and functions that the administrators of these networks deem important/mandatory, and are not willing to set aside in this migration which arenÆt available or defined in IP yet. Accomplishing certain of these functionalities is similar to fitting a round peg into a square hole. MLPP is circuit-based technology, and IP is packet-based. To accomplish a task that is easy within MLPP, such as Look ahead For Busy (LFB), which ensures that one phone has a clear and open path to make a call to another phone, even though the calling phone hasn't started to make the call, and might not for seconds, minutes or hours, makes sense in the networks where MLPP exists presently; but that feature makes little to no sense in IP networks where available bandwidth is freely given on a best effort basis through any internetworking interface at that moment û much less reserving that bandwidth for future use, if used at all. An exception does exist in IP for this example, but it only reserves bandwidth end-to-end if that bandwidth is available through each transit Router, and upon set-up of that symmetrical session that is about to occur, not before. MLPP has very little impact on end devices like the phones because all the signaling and processing is in the EOS, not the phone. Signaling mecha- nisms that have stateful awareness, and have this resource reservation feature enabled from the example above have a great impact on the processor of that end device (IP Phone) the way the IETF Protocols are written today. IP has no physical circuit endpoint to map to in these transit Routers (unlike the EOS or TN in MLPP networks); no easy way to reserve a fixed portion of bandwidth; in fact, these transit Routers almost never know which packet belongs to which session going through it, or that any sessions are going through it. These administrators understand that IP Telephony offers significant increases in features, functionality and services for all end-users. However, there has not yet been an effort to describe this architecture with IP. This document takes that challenge. 4.0 MLPP Requirements in any Network This section details the requirements of MLPP without IP and, as best as can be accomplished, without ISDN or SS7. Many circuit-switched nomen- clatures and references (words, not bibliographical) will be made due to MLPP only existing in the circuit-switched world to this point in time. It is an attempt at a generic, yet specific set of network requirements for any network to function as an MLPP compliant network; and yet not too specific to the circuit-switched world as to detail Bellcore's Local Access Transport Area (LATA) Switching Systems Generic Requirements Polk draft-polk-mlpp-over-ip-01.txt Page 8 Internet Draft MLPP over IP Nov 21st, 2001 (LSSGR), FR-64. Where possible, language will exist that attempts to convey whatever tone or spirit these MLPP references make to these requirements û for clarity and understanding in making IP equivalents and solutions for MLPP in a packet environment. For this to happen, the core MLPP documents [1 & 2] must be referenced in detail, as well as the documents involving the actual testing of any component for certification of MLPP compliance [17,18,19]. The root specification [1] states that there are two parts to MLPP conceptually: Precedence and Preemption. 4.1 MLPP Precedence Precedence means Priority, relative priority to all other calls within that single domain. It is set or assigned by the calling party at the beginning of a call, on a per call basis by that party. Once the precedence level is chosen by a caller, it cannot be changed for the duration of that call. However, the next call being independent of the first call, can be made at another authorized level, also chosen by the calling party. Precedence Values are: 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 above list of precedence levels are listed in order from highest to lowest; meaning no call SHALL be of higher priority than "Flash Override" in an MLPP domain, the "Flash", and so on down to "Routine" as the lowest level able to be signified. "Routine" is for normal, everyday phone calls. The unspecified values, if ever used, are to have priority levels below that of "Routine"; none have been utilized to date [17]. The Precedence levels authorized for a phone are set up for that circuit, ensuring the user of that phone cannot use a level above what they are authorized to gain access to. 4.2 MLPP Preemption Preemption is the seizing of otherwise used resources of one or more calls in order to complete another call in a congestion situation. This is determined by EOS's or TN's evaluating or comparing the Precedence levels of all existing calls outbound on a circuit or a trunk, upon a time of congestion or no other resources available on that same interface, with the level of the next inbound call (set-up) intended to egress that same interface. One or more resources can be cleared for a higher precedence level call, ensuring that call the newly available resources. Polk draft-polk-mlpp-over-ip-01.txt Page 9 Internet Draft MLPP over IP Nov 21st, 2001 There are two modes of Preemption: preemption of the called device with another inbound higher precedence call (Access Preemption), and preemption within the network not involving either party of the preempted call at all, but at a point of congestion (Network Preemption). MLPP is mandated as having influence with a single domain based imple- mentation 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 was included for this reason into the ISDN signaling for MLPP service. 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; 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 not originating in that 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 gets disconnected first. 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, 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 Polk draft-polk-mlpp-over-ip-01.txt Page 10 Internet Draft MLPP over IP Nov 21st, 2001 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. MoIP might want to standardize this mechanism for consistency. Who the preemption picks to get whacked is not defined within the requirements. So it's up to the implementers. My thought of a stateful timer assigned to each interface that picks either who is on the lowest level the shortest or longest gets it. MLPP [1] also established the Alternative Party, and the Non-Preemptable Resources options. The Alternative Party option is a pre-configured to that phone-line secondary phone to ring in the times where the first 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. An additional benefit to the Timer T sub K is that it prevents indefinite diversions when it expires for a call. The example below give this mechanism more clarity. 4.2.1 Access Preemption Event The following is an example of the MLPP mandated process for Access-based Preemption events occur, similar to a flow chart: Scenario #1: Caller A and D are on an MLPP call when Caller 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 speci- fied; C is Disconnect (Precedence Call Blocked indication) if one isn't specified. If the MLPP call from C has a greater Precedence value than the A to D call, then a determination is made 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 Preempt- able, 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: Polk draft-polk-mlpp-over-ip-01.txt Page 11 Internet Draft MLPP over IP Nov 21st, 2001 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. 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. 4.2.2 Network Preemption Event The following is an example of the MLPP mandated process for Network-based Preemption events 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 If there is an existing MLPP call between two parties (A & B), and an unrelated MLPP call to either A or B has a higher Precedence level than the A-B call, the network first checks to see if there are available resources for that new call; 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 to B and C to D, there is now a search at that interface for Preemptable resources. 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, however, 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, now 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) 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.3 MLPP Feature Scenarios 4.3.1 Bearer Services Supported MLPP [1] is applicable to the following circuit-mode bearer services: Polk draft-polk-mlpp-over-ip-01.txt Page 12 Internet Draft MLPP over IP Nov 21st, 2001 o Speech o 3.1kHz audio (video-band data), and o 64kbps unrestricted data 4.3.2 Commonalities of Interest The Commonalities of Interest (COI) scenario is a configuration within the MLPP Domain such that a limited group of users primarily call each other, and few others. This group shall have enhanced or reduced treatment of call attempts within their assigned group. This configuration has the choice of optionally allowing Higher Precedence calls specifically to another within the group, or this capability is not allow. Call detail recording shall record all Precedence call attempts from this type of group. 4.3.3 Conferences Preset This is a preset configured list of attendees to a conference bridge identified by the number and key dialed at the originator's station. All EN, EOS, MFS shall be capable of simultaneously having 10 such conferences with up to 20 configured endstations for each conference. The ability to add up to 5 additional participants utilizing Hook-Flash by the initiator of the conference is permitted as well. Each conference shall have a Precedence level set by the originator of that conference bridge. Preemption shall occur as already specified û meaning, conferences bridges do not get preferential treatment beyond the precedence level the bridge is set to. A special condition exists within this functionality, if the originator of a conference is preempted, the preempt tone occurs for two seconds to all attendees, and then the bridge is disconnected to all. This includes those who were not, under other condition, subject to a preemption event. 5.0 MoIP Requirements and solutions Based on the previous sections, requirements for what is mandatory and optional in any network to be MLPP compliant, here is an overview of the technologies that the IETF offers. What will be mentioned are how certain protocols shall and shall not be utilized to satisfy the MLPP require- ments. Although this is an Informational-Track document defining an Architecture, this section shall be written as if it was a Standards Track document with all the associated RFC2119 language mandating this SHALL occur, that SHALL NOT occur, and RECOMMENDED practices that are highly desirable if imple- mented. This should give the reader a sense of the tone of this Archi- tecture and what is needed to ensure it is as close to compliance as possible to the intent of MLPP. Because MLPP is principally a symmetrical natured transport, meaning that traffic is bi-directional and typically almost identical in the number of packets traveling each direction, this document is for unicast traffic Polk draft-polk-mlpp-over-ip-01.txt Page 13 Internet Draft MLPP over IP Nov 21st, 2001 only. Multicast traffic in MoIP is to be defined at a later date once the case and need is presented to this document's author or if by chance this effort moves into a WG, and it becomes subject to that WG's consensus charter and directions. MoIP can be broken into several areas of interest or specialization from an IETF perspective: Header Marking, Routing, Signaling and/or Call Control, and Media. A logical migration of MLPP into MoIP is migrate towards multimedia communications, while maintaining more or less a symmetrical communication service in nature. In other words, although now to include video, it shouldn't yet take on single-directional broadcasts of a video feed, whether live or recorded. A possibility comes to mind in High Priority announcements to a select few receivers. But this likely would include multicast transmissions as well, and that is outside the scope of this document in its current intent. Without losing focus on MLPP û that Standard [1&2] specifies two basic features for a communications session within a compliant Domain: o Setting the Precedence level of each session upon initiation of that session, and o Recognizing congested interfaces and preempting traffic for higher precedence traffic 5.1 Setting Priority to an MoIP Session Presently there are three IETF-based mechanisms for Signaling or Controlling the Precedence/Priority end-to-end: o SIP (Standard) o MEGACO (Standard) o MGCP (Informational only) Presently there exist two IETF-based mechanisms to set (not signal) Priority to a communications stream from end-to-end û with one more potentially coming: o Diffserv [3] o RSVP [10] o Potentially coming from the IETF: NSIS o others at layer 2 An additional mechanism exists for propagating preferential treatment of Packet flows, but more in a core-type environment: MPLS 5.2 SDP in MoIP The extension of this protocol doesn't augment any function specifically for MoIP. This is specifically for session capabilities exchange nego- tiation. A domain is either MoIP compliant or not. Little is negotiated, especially at the level. Polk draft-polk-mlpp-over-ip-01.txt Page 14 Internet Draft MLPP over IP Nov 21st, 2001 5.3 SIP in MoIP The Session Initiation Protocol (SIP) [6] "is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution." As a Signaling Protocol, this is an ideal candidate for conveying the Precedence level from the Calling party to the Called party. In SIP language, one UA includes a Request, General or Requires Header-Field in the initial INVITE message to that second (or more) UA(s). The existing Priority Header-Field is for receiver information only, so a new header- Field is needed. This header-Field can't be a Requires Header-Field, as SIP UA's will call outside the MoIP domain, and this header-Field might not be supported, causing either an error or confusion. Either of which is not good for successful communications. It can be either a Request Header- Field with a Response Header-Field returned from the far-end UA, or a General Header-Field, in which the far-end UA replicates the Header-Field in the reply. An Internet Draft has been submitted for this new Header-Field called Resource Priority Header [15]. This ID is not a WG item within the SIP (it was just submitted). However, it matches the RFC 791 [5] and MLPP Precedence levels with one additional level: "Critical/Emergency Call Priority" (CRITIC/ECP), which is in [5]. This new level is specifically for situations such as 9/11/01 for Government level Emergency Preparedness and Response [16]. However, no MoIP users shall have the ability to access this higher CRITIC/ECP level unless they go through the procedures that all other authorized personnel do when access this Preferential communi- cations service. The network treatment of such a communication set-up is outside the scope of this document for now. This new ID is specifically written loosely for wide appeal. Here, once that document becomes a Working Group Item officially (then RFC) it shall have much more stringent language here to strengthen what it will do in MoIP domains. More on this is coming versions of both documents. Under the SIP Signaling model for MoIP communications, the Proxy Servers [6] SHOULD be the policers or filters of the SIP signaling packets within the MoIP domain. Redirect Servers [6] can also perform this function. It's unclear in the MoIP domain whether SIP Registrar Servers [6] will have as much control as most believe. Registrar Servers aren't required in order to have SIP communications. Their intent was originally for Mobil- ity, but that has was a lost belief in the SIP community for quite some time, until recently when Dean Willis stated that, as WG Co-Chair, the Registrar Server ought to be renamed to be clearer to its intent from inception of SIP. Again, further revisions of this document will have updates to this sub-item. Just as with MLPP, it's true with MoIP using SIP: Precedence levels are set at session initiation and CANNOT be altered during a session. Addi- tionally, the last Precedence level requested for a session does NOT reset the UA's default to that new level û the Precedence level MUST start at default without user intervention at "Routine". Polk draft-polk-mlpp-over-ip-01.txt Page 15 Internet Draft MLPP over IP Nov 21st, 2001 The exceptions within the IP world are obviously when taking advantage of what the circuit-switched world can't do: Determine who is making the session request. Modern user authentication mechanisms can verify who is making the call or information transfer. In such cases, with MoIP domain administrator's permission, the default Precedence level should be allowed to be user authorized and selected. Future versions of this document will likely have this topic broken out into its own section for thorough analysis. SIP UA's MUST allow Access Preemption to occur in MoIP networks. Addi- tionally, SIP MUST implement Alternative Party redirect (REFER Method); but this might be one option of many ways of doing this function. Conference Bridge Applications could be accomplished through a Proxy initiated INVITE to all parties of that bridge. The list of attendees could be dynamically set up with a Third Party interface into that Proxy Server, with the Precedence level of all sessions set at that time prior, and by an authenticated originator. A mixer can also receive an INVITE for voice mixing instead of having a UA end device do all this function. 5.4 MEGACO in MoIP MEGACO as defined in [9] is a Media Gateway Control Protocol. It consists of two major parts: Media Gateways (MG) and the Media Gateway Controller (MGC). Media Gateways translate signals from one type of network to another type of network. Both interfaces don't know about the other. In fact, the Gate- way makes the experience such that both end devices don't know theyÆre communicating outside of their native protocol, whatever that might be: IP, TDM, Audio, Carrier wave, Analog circuitry, ISDN, Digital Trunks, RF frequency... anything to anything, as long as that Gateway is built for that. Media Gateway Controllers control the Media Gateways. The intention of MEGACO (and MGCP, which is the next section) is to have fair dumb end- stations and very smart Servers being the brains for those endstations, or Terminations. MEGACO has 8 Primitives or commands: Add: Adds a termination (an endpoint) Modify: Modifies the properties of a termination Subtract: Subtracts or disconnects a termination Move: Moves a termination to another context AuditValue: Returns the current values of properties, events, signals and statistics AuditCapabilities: Returns the possible values of properties, events, signals and statistics Notify: Allows the media gateway to notify the MGC of events within MG ServiceChange: Allows MG to inform MGC it is going in or out of service Polk draft-polk-mlpp-over-ip-01.txt Page 16 Internet Draft MLPP over IP Nov 21st, 2001 MEGACO MUST allow Access Preemption to occur in MoIP networks. Addi- tionally, MEGACO MUST implement Alternative Party redirect; but this might be one option of many ways of doing this function. Conference Bridge Applications could be accomplished through the MGC to all parties of that bridge. The list of attendees and the DSP doing the mixing could be dynamically set up with a Third Party interface into that MGC, with the Precedence level of all sessions set at that time prior, and by an authenticated originator (maybe through a Web interface app). Further investigation is needed to ensure MEGACO has the existing mecha- nisms for MoIP. 5.5 MGCP for MoIP MGCP [8] is also a Media Gateway Control Protocol, but one that isn't Standardized within the IETF, or anywhere. It is, however, deployed in a wide range of vendor solutions û significantly more so than MEGACO. This is as much to do with the timing of the Protocol û it was first to the field, by more than a year. That kind of a head start in the VoIP intensive explosion weÆre just starting can put a protocol out in the market lead for a long time as a Defacto Standard. MGCP is rooted in the combination of IPDC from Level 3 Corporation and SGCP from Bellcore. It has 8 primitives as well as MEGACO: EndpointConfiguration (EPCF): Instructs gateway about coding char- acteristics of 'line-side' of the endpoint NotificationRequest (RQNT): Instructs the Gateway to watch for specific events Notify (NTFY): Inform CA when requested events occur CreateConnection (CRCX): Create a connection to an "Endpoint" inside the Gateway ModifyConnection (MDCX): Change the parameters associated with an established connection DeleteConnection (DLCX): Delete an existing connectionùAck returns call statistics AuditEndPoint (AUEP) and AuditConnection (AUCX): Audit the status of an "endpoint" and any connections associated RestartInProgresss (RSIP): Notifies the CA an endpoint (or group of endpoints) is taken out of service MGCP MUST allow Access Preemption to occur in MoIP networks. Addi- tionally, MGCP MUST implement Alternative Party redirect; but this might be one option of many ways of doing this function. Conference Bridge Applications could be accomplished through the MGC to all parties of that bridge. The list of attendees and the DSP doing the mixing could be dynamically set up with a Third Party interface into that MGC, with the Precedence level of all sessions set at that time prior, and by an authenticated originator (maybe through a Web interface app). Further investigation is needed to ensure MGCP has the existing mechanisms for MoIP. Polk draft-polk-mlpp-over-ip-01.txt Page 17 Internet Draft MLPP over IP Nov 21st, 2001 5.6 Differentiated Services in MoIP [3] was created to provide this in a packet forwarding mode. This involved creating a new function by obsoleting the first 6 bits of the old Type of Service Byte in the IPv4 Header [5]. This new function focused purely on the Router's forwarding queue and defining behaviors for packets marked a certain way (with a certain value), and leaving other packet mark values up to the local administrator to determine the behavior through that administrator's infrastructure. That's the rub with Diffserv as a primary mechanism for Precedence level marking of packets in MoIP. [3] states clearly that packets are marked at the edge of boundary of a Diffserv Domain with what those authors called an Edge Router. If properly policed, this ensured proper forwarding and traffic engineering within that domain. Diffserv has no session awareness, so Preemption of an entire session would be clearly impossible based solely on this packet marking mechanism. Diffserv should be utilized in packet forwarding, but another problem arises when any packet leaves domain û it gets remarked by that next domain's Edge Routers. This occurs at will and often today. Current practice has most implementers of VoIP utilizing DSCP 101110 for EF [12]. This mandates not packet shall precede an EF marked packet in the forwarding queue of a Router other than an other EF marked packet which got into the queue before it. MoIP requires a distinction and a difference in the treatment of packets from one another by session, not application. Diffserv prioritizes packets, not sessions, in fact has no session awareness û therefore lack the preemption capability within it of while using it. Perhaps a well thought out AF [13] DSCP marking where nothing is marked EF within the entire domain. This has tremendous potential due the drop characteristics of the AF classes if thoroughly maintained and policed within a domain û which will be daunting at best. AF has the ability to drop packets in any of the 12 queues at predictable rates while not termi- nating the sessions. Although AF wasn't intended to be used a 12 consecu- tive queues, but as classes of up to 3 (AF11, AF12 and AF13 for example). Below is the chart from [13] detailing the codepoint markings and packet drop characteristics per class: The RECOMMENDED values of the AF codepoints are as follows: AF11 = ' 001010', AF12 = '001100', AF13 = '001110', AF21 = '010010', AF22 = ' 010100', AF23 = '010110', AF31 = '011010', AF32 = '011100', AF33 = ' 011110', AF41 = '100010', AF42 = '100100', and AF43 = '100110'. The table below summarizes the recommended AF codepoint values. Class 1 Class 2 Class 3 Class 4 +----------+----------+----------+----------+ Low Drop Prec | 001010 | 010010 | 011010 | 100010 | Medium Drop Prec | 001100 | 010100 | 011100 | 100100 | High Drop Prec | 001110 | 010110 | 011110 | 100110 | +----------+----------+----------+----------+ Polk draft-polk-mlpp-over-ip-01.txt Page 18 Internet Draft MLPP over IP Nov 21st, 2001 The AF groupings AF1X, AF2X, AF3X and AF4X are separate classes that are not defined to in order relative to each other. The behavior or treatment definition is within each class. Two AF classes could be used within a single MoIP Domain that MUST NOT have EF marked for Multimedia can appropriately build a L3 MoIP behavior within a Single Building, Campus or Base. Mapping this AF Behavior Aggregate (AF BA) properly to MPLS Label Switch Path (LSP) could extend this Preferential Treatment functionality desired in MoIP on a wider scale [28]. The AF DSCP value MUST be set by the Precedence level Request within the SIP INVITE with the Resource Header, or conveyed by the MGC in either MEGACO or MGCP. In VoIP, but not data transfers, packets can be dropped without loosing a session, and the degradation will increase as the congestion gets worse, but the session will stay up with more like bad Cell phone quality instead of Toll Quality. If communications is important and quality not so import- ant, this is a viable option if the session awareness is solved for full preemption in cases of need. Filtering out EF at layer 3 is harsh and ugly, but might be necessary in a complementary role with other mechanisms and protocols in MoIP. 5.7 RSVP in MoIP RSVP [10] in concept has most of what MoIP requires, but few are adopting it in the end device. The end device determines the bandwidth necessary for a bi-directional communication stream and sends a PATH packet out to the destination device communicating with all supporting internetworking devices along the way. The destination device would answer the request packet with a RESV message, with the internetworking devices all along the way clearing the bandwidth (if available) for end-to-end communications at a fixed bandwidth. It has a policy co-worker, for lack of a better way of putting it, in COPS or Common Open Policy Service [11] with a defined mechanism for Preemption priority policy element in [25]. Most of the hits against RSVP are regarding Mobility (or lack of support of), no End-to-Edge reservations and the one consistent hit RSVP has taken is it's heavyweight nature of implementation. In other words, it's hard to code û especially in smaller devices like IP Phones which MoIP must support. NSIS is supposed to be a new WG forming for this reason. RSVP does lack one feature that's minimally utilized: Look ahead For Busy (LFB) to ensure that a path between two devices is available for a call in the future. 5.8 NSIS in MoIP "Next Steps in Switching" is a proposed WG within the IETF to potentially solve some of the deficiencies of RSVP while taking advantage of its strengths. Many Internet Drafts exist already within that effort. [26] references specifically RSVP and why it should be modified. More on this effort will be in the next version of this draft Polk draft-polk-mlpp-over-ip-01.txt Page 19 Internet Draft MLPP over IP Nov 21st, 2001 5.9 MPLS in MoIP The MPLS concept assigns short fixed length labels to packets at the ingress to an MPLS cloud to identify a Forwarding Equivalence Class (FEC) [4]. This ingress is called a Label Switch Router. Throughout the MPLS cloud or domain, the labels attached to packets are used to make for- warding decisions [27]. "MPLS protection" is defined in [28] as Because MPLS is path-oriented it can potentially provide faster and more predictable protection and restoration capabilities in the face of topology changes than conventional hop by hop routed IP systems." MPLS is not intended for a campus solution û which a Base would most categorically fall into. The use of AF BA's mentioned previously, mapped to the LSP's of MPLS at the ingress LSR, with MPLS Protection (above) would at this time like provide the clearest solution for MoIP. In MoIP where MPLS is utilized, a FEC MUST be set up in all LSR's for each Precedence level and the CRITIC/ECP level. This will allow proper mapping of Precedence levels to AF BA's (when chosen as well) within the campus or Base infrastructure, and on to the MPLS Cloud in between Bases in the core of the DSN network that is MoIP compliant. If the EF DSCP is utilized as well, regardless of the reason, a separate LSP SHALL exist in all LSR's for it as well. If RSVP is utilized in the Campus or Base level, [27] describes tunnels in MPLS, which can be mapped to RSVP Paths from [29]. If such a case, all packets could and should have the EF DSCP. 5.10 RTP for MoIP Media Payload shall be provided with Real-Time Protocol [7] for voice, video and real-time collaboration. RTP requires little adjusting or extending other than the possibility of marking the RTP Headers with the matching precedence level that was Signaled by the Signaling or Control Protocol exchange between end devices. An Internet Draft has been introduced for this RTP extension [14] in the AVT WG. This ID also has the 6th Precedence Level CRITIC/ECP for the GETS communications Service [16]. Little else is evident that RTP needs to further support MoIP. 5.11 Gateway Requirements Regardless of Protocol Regardless of the Signaling or Control Protocol used within the MoIP Domain, IP-to-MLPP signaling MUST adhere to the MLPP requirements set forth in [1,2,17,18,19] regardless of what L2 technology is utilized on either side or both. There will likely be islands of MoIP connecting to the existing MLPP network. This translation MUST be seamless to the network elements and MUST be seamless to the users on either end of a communications session/call. This MUST include the transparent signaling of the Precedence level set on one side of the Gateway to the other side with no alterations when the Polk draft-polk-mlpp-over-ip-01.txt Page 20 Internet Draft MLPP over IP Nov 21st, 2001 Gateway in between MLPP and MoIP network. When the Gateway is communi- cating with a MOM-MLPP network, the MoIP administrator can chose what ingress Precedence Level those calls should be set to. Default should be "Routine"; but there might a certain dialed in circuit translates to a certain Precedence Level situation. 6.0 IANA Considerations There are no IANA considerations with this document 7.0 Security Considerations It's obvious when a mechanism is utilized for preempted one traffic flow over another, it has security considerations. However, this document is a combination document mandating the watchful control by Government hired employees that are already overseeing an identical network in concept û so the transition to IP from a oversight position shouldn't be too different. That said, misuse of preemption is a concern, even when limited to a single domain, albeit a large one. 8.0 Changes since last version Increased the requirements of MLPP network compliance. Broke out the involved IETF Protocols for clarity and analysis of how each function with regard to MoIP requirements. Added MPLS for Domain Core analysis. Added a Gateway Requirements section for the transition between MLPP and MoIP networks. Added the references to the Internet Drafts that are currently active attempting to extend which Protocols and procedures are necessary for enabling IP to meet the requirements of an MoIP network. 9.0 Acknowledgements To Brian Rosen for encouragement and motivation. To Captain Gordon Bradley (Can. AF) for his aid in gathering the information and scope of this effort. 10.0 References [1] ANSI specification ANSI T1.619-1992. [2] ANSI specification ANSI T1.619A-1994. [3] RFC 2475 "An Architecture for Differentiated Service", S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, December 1998 Polk draft-polk-mlpp-over-ip-01.txt Page 21 Internet Draft MLPP over IP Nov 21st, 2001 [4] RFC 3031 "Multiprotocol Label Switching Architecture", E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta, January 2001 [5] RFC 791 "Internet Protocol", J. Postel, Sept 1981 [6] RFC 2543, "SIP: Session Initiation Protocol", M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg March 1999 [7] RFC 1889 "RTP: A Transport Protocol for Real-Time Applications", H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, January 1996 [8] RFC 2705 "Media Gateway Control Protocol(MGCP) Version 1.0", M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett, October 1999 [9] RFC 3015 "MEGACO Protocol Version 1.0", F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers, November 2000 [10] RFC 2205 "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", R. Ed. Braden, L. Zhang, S. Estrin, S. Herzog, and S. Jamin, September 1997. [11] RFC 2748 "The COPS (Common Open Policy Service) Protocol" D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, January 2000 [12] RFC 2598 "An Expedited Forwarding PHB" RFC 2598, V. Jacobson, K. Nichols, K. Poduri, June 1999 [13] RFC 2597 "Assured Forwarding PHB Group", J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, June 1999 [14] "draft-polk-avt-rtpext-res-pri-00.txt" IETF Internet Draft, J. Polk, November, 2001. Work in Progress [15] "draft-polk-sip-resource-00.txt", J. Polk, H. Schulzrinne IETF Internet Draft, November, 2001. Work in Progress [16] "Framework for supporting IEPS in IP telephony", K. Carlberg and I. Brown, IETF Internet Draft, Oct. 2001. Work in Progress [17] "Generic Switching Center Requirements" (GSCR), JIEO Technical Report 8249, March 1997 [18] Defense Switched Network "Generic Switching Test Plan" (GSTP), June 1999 [19] ITU-T Recommendation Q.735.3 (1993), "Description for Community of Interest Supplementary Services using SS7 - Multilevel precedence and preemption" [20] "draft-polk-mlpp-over-ip-00.txt", IETF Internet Draft, J. Polk, Feb 2001. Work in Progress [21] ANSI T1.604-1990 "Integrated Services Digital Network (ISDN)" Polk draft-polk-mlpp-over-ip-01.txt Page 22 Internet Draft MLPP over IP Nov 21st, 2001 [22] ANSI T1.113-1988 "Signaling System Number 7 (SS7) û ISDN User Part" [23] ANSI T1.604-1990 "ISDN û Layer 3 Signaling Specification for Circuit-Switched Bearer service for Digital Subscriber System Number 1 (DSS1)" [24] ANSI T1.610-1990 "DSS1 û Generic Procedures for the Control of ISDN Supplementary Services" [25] RFC 3181 "Signaled Preemption Priority Policy Element" S. Herzog, Oct 2001 [26] "draft-greis-rsvp-analysis-00.txt" IETF Internet Draft, M. Greis, Nov 2001. Work in Progress [27] RFC 2702 "Requirements for Traffic Engineering Over MPLS", D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, September 1999. Work in Progress [28] "draft-ietf-mpls-diff-ext-09.txt", F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen, April, 2001. Work in Progress [29] "draft-ietf-mpls-rsvp-lsp-tunnel-09.txt", D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, August 2001. Work in Progress 11.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 re- voked by the Internet Society or its successors or assigns. Polk draft-polk-mlpp-over-ip-01.txt Page 23 Internet Draft MLPP over IP Nov 21st, 2001 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: May 22nd, 2002 Polk draft-polk-mlpp-over-ip-01.txt Page 24