Network Working Group F. Baker Internet-Draft Cisco Systems Expires: May 31, 2004 December 2003 Implementing MLPP in the Internet Protocol Suite draft-baker-tsvwg-mlpp-that-works-00 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. This Internet-Draft will expire on May 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The Defense Information Systems Agency of the United States Department of Defense, with is contractors, has proposed a service architecture for military (NATO and related agencies) telephone systems. This is called the Assured Service, and is defined in two documents: "Architecture for Assured Service Capabilities in Voice over IP" and "Requirements for Assured Service Capabilities in Voice over IP". Responding to these are three documents: "Reason Header Field for the Session Initiation Protocol", "Extending the Session Initiation Protocol Reason Header to account for Preemption Events", "Communications Resource Priority for the Session Initiation Protocol". What remains to this specification is to provide a Call Admission Baker Expires May 31, 2004 [Page 1] Internet-Draft MLPP for VoIP December 2003 Control procedure and a Per Hop Behavior for the data which meet the needs of this architecture. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Multi-Level Preemption and Precedence . . . . . . . . . . . 3 1.2 Assumptions about the Network . . . . . . . . . . . . . . . 5 1.3 Assumptions about application behavior . . . . . . . . . . . 5 1.4 Desired Characteristics in an Internet Environment . . . . . 6 1.5 The use of bandwidth as a solution for QoS . . . . . . . . . 7 2. Solution Proposal . . . . . . . . . . . . . . . . . . . . . 9 2.1 Call admission/preemption procedure . . . . . . . . . . . . 10 2.2 Voice handling characteristics . . . . . . . . . . . . . . . 10 2.3 Bandwidth admission procedure . . . . . . . . . . . . . . . 11 2.3.1 Alternatives that fall short . . . . . . . . . . . . . . . . 11 2.3.2 Recommended procedure: explicit call admission - RSVP Admission using Policy . . . . . . . . . . . . . . . . . . . 12 2.4 Authentication and authorization of calls placed . . . . . . 14 2.5 Defined User Interface . . . . . . . . . . . . . . . . . . . 14 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . 22 Baker Expires May 31, 2004 [Page 2] Internet-Draft MLPP for VoIP December 2003 1. Overview The Defense Information Systems Agency of the United States Department of Defense, with is contractors, has proposed a service architecture for military (NATO and related agencies) telephone systems. This is called the Assured Service, and is defined in two documents: "Architecture for Assured Service Capabilities in Voice over IP" [25] and "Requirements for Assured Service Capabilities in Voice over IP" [26]. Responding to these are three documents: "Reason Header Field for the Session Initiation Protocol" [22], "Extending the Session Initiation Protocol Reason Header to account for Preemption Events" [23], "Communications Resource Priority for the Session Initiation Protocol" [24]. What remains to this specification is to provide a Call Admission Control procedure and a Per Hop Behavior for the data which meet the needs of this architecture. 1.1 Multi-Level Preemption and Precedence Before doing so, however, let us discuss the problem that MLEF is intended to solve and the architecture of the system. The Assured Service is designed as an IP implementation of an existing ITU-T/ NATO/DoD telephone system architecture known as Multi-Level Precedence and Preemption [27][28][29], or MLPP. MLPP is an architecture for a prioritized call handling service such that in times of emergency in the relevant NATO and DoD commands, the relative importance of various kinds of communications is strictly defined, allowing higher priority communication at the expense of lower priority communications. These priorities, in descending order, are: Flash Override Override: used by the Commander in Chief, Secretary of Defense, and Joint Chiefs of Staff, Commanders of combatant commands when declaring the existence of a state of war. Flash Override: used by Commander in Chief, Secretary of Defense, and Joint Chiefs of Staff, Commanders of combatant commands when declaring the existence of a state of war. Flash: reserved generally for telephone calls pertaining to command and control of military forces essential to defense and retaliation, critical intelligence essential to national survival, conduct of diplomatic negotiations critical to the arresting or limiting of hostilities, dissemination of critical civil alert information essential to national survival, continuity of federal government functions essential to national survival, fulfillment of critical internal security functions essential to national Baker Expires May 31, 2004 [Page 3] Internet-Draft MLPP for VoIP December 2003 survival, or catastrophic events of national or international significance. Immediate: reserved generally for telephone calls pertaining to situations that gravely affect the security of national and allied forces, reconstitution of forces in a post-attack period, intelligence essential to national security, conduct of diplomatic negotiations to reduce or limit the threat of war, implementation of federal government actions essential to national survival, situations that gravely affect the internal security of the nation, Civil Defense actions, disasters or events of extensive seriousness having an immediate and detrimental effect on the welfare of the population, or vital information having an immediate effect on aircraft, spacecraft, or missile operations. Priority: reserved generally for telephone calls requiring expeditious action by called parties and/or furnishing essential information for the conduct of government operations. Routine: designation applied to those official government communications that require rapid transmission by telephonic means but do not require preferential handling. The rule, in MLPP, is that more important calls override less important calls. MLPP is built as a proactive system in which callers must assign one of the precedence levels listed above at call initiation; this precedence level cannot be changed throughout that call. If there is end to end capacity to place a call, any call may be placed at any time. However, when any trunk (in the circuit world) or interface (in an IP world) reaches utilization capacity, a choice must be made as to which call continues. The system will seize the trunks or bandwidth necessary to place the more important calls in preference to less important calls by preempting an existing call (or calls) of lower precedence to permit a higher precedence call to be placed. More than one call might properly be preempted if more trunks or bandwidth is necessary for this higher precedence call. A video call (perhaps of 384 KBPS, or 6 trunks) is a good example of this situation. This is occurs when the called handset is in use (the general calls the colonel, who at the time is talking with the captain), or may be used to clear a circuit (all circuits are busy, but a lower precedence call may be cleared to create room for the higher precedence call). When preemption happens, each preempted speaker will hear an audible tone indicating they have just been preempted. In this example, the colonel and the captain will each hear a audible tone indicating s/he must hang up; upon doing so, the colonel will receive the incoming call from the general. Baker Expires May 31, 2004 [Page 4] Internet-Draft MLPP for VoIP December 2003 1.2 Assumptions about the Network IP networks generally fall into two categories: those with constrained bandwidth, and those that are massively overprovisioned. In a network wherein over any interval that can be measured (including sub-second intervals) capacity exceeds offered load by at least 2:1, the jitter and loss incurred in transit are nominal. This is generally a characteristic of properly engineered Ethernet LANs and of optical networks (networks that measure their link speeds in multiples of 51 MBPS); in the latter, circuit-switched networking solutions such as ATM, MPLS, and GMPLS can be used to explicitly place routes, and so improve the odds a bit. Between those networks, in places commonly called "inter-campus links", "access links" or "access networks", for various reasons including technology and cost, it is common to find links whose offered load can approximate or exceed the available capacity. Such events may be momentary, or may occur for extended periods of time. In addition, primarily in tactical deployments, it is common to find bandwidth constraints in the local infrastructure of networks. For example, the US Navy's network afloat connects approximately 300 ships, via satellite, to five network operation centers, and those NOCs are in turn interconnected via the DISA backbone. A typical ship may have between two and six radio systems aboard, and it is unusual for any of them to exceed 64 KBPS due to a combination of encryption and allocation constraints. In US Army networks, current radio technology likewise limits tactical communications to links below 100 KBPS. Future radio capabilities are projected to be on the order of 1-10 MBPS, and certainly less than 45 MBPS. Over this infrastructure, military communications expect to deploy voice communication systems (30-80 KBPS per session), video conferencing using MPEG 2 (3-7 MBPS) and MPEG 4 (80 KBPS to 800 KBPS), in addition to traditional mail, file transfer, and transaction traffic. 1.3 Assumptions about application behavior Parekh and Gallager [30][31] published a series of papers analyzing what is necessary to ensure a specified service level for a stream of traffic. In a nutshell, they showed that to predict the behavior of a stream of traffic in a network, one must know two things: o the rate and arrival distribution with which traffic in a class is introduced to the network, and o what network elements will do, in terms of the departure Baker Expires May 31, 2004 [Page 5] Internet-Draft MLPP for VoIP December 2003 distribution, injected delay jitter and loss characteristics, with the traffic they see. For example, TCP tunes its effective window (the amount of data it sends per round trip interval) so that the ratio of the window and the round trip interval approximate the available capacity in the network. As long as the round trip delay remains roughly stable and loss is nominal (which are primarily behaviors of the network), TCP is able to maintain a predictable level of throughput. In an environment where loss is random or in which delays wildly vary, TCP behaves in a far less predictable manner. Voice and video systems do not tune their behavior to that of the network. Rather, they send traffic at a rate specified by the codec depending on what it perceives is required. In an MPEG-4 system, for example, if the camera is pointed at a wall, the codec determines that an 80 KBPS data stream will describe that wall, and issues that amount of traffic. If a person walks in front of the wall or the camera is pointed an a moving object, the codec may easily send 800 KBPS in its effort to accurately describe what it sees. In commercial broadcast sports, which may line up periods in which advertisements are displayed, the effect is that traffic rates suddenly jump across all channels at certain times because the eye-catching ads require much more bandwidth than the camera pointing at the green football field. As described in RFC 1633 [1], when dealing with a real-time application, there are basically two things one must do to ensure Parekh's first requirement. To ensure that one knows how much offered load the application is presenting, one must police (measure load offered and discard excess) traffic entering the network. If that policing behavior has a debilitating effect on the application, as non-negligible loss has on voice or video, one must admit sessions judiciously according to some policy. A key characteristic of that policy must be that the offered load does not exceed the capacity dedicated to the application. In the network, the other thing one must do is ensure that the application's needs are met in terms of loss, variation in delay, and end to end delay. One way to do this is to supply sufficient bandwidth that loss and jitter are nominal. Where that cannot be accomplished, one must use queuing technology to deterministically apply bandwidth to accomplish the goal. 1.4 Desired Characteristics in an Internet Environment The key elements of the MLPP service include the following: Baker Expires May 31, 2004 [Page 6] Internet-Draft MLPP for VoIP December 2003 Call Admission/Preemption Policy: There is likewise a clear policy regarding calls that may be in progress at the called instrument. During call admission (SIP/H.323), if they are of lower precedence, they must make way according to a prescribed procedure. All callers on the preempted call must be informed that the call has been preempted, and the call must make way for the higher precedence call. Bandwidth Admission Policy: There is a clear bandwidth admission policy: sessions may be placed which assert any of several levels of precedence, and in the event that there is need and authorization is granted, other sessions will be preempted to make way for a call of higher precedence. Authentication and Authorization of calls placed: Unauthorized attempts to place a call at an elevated status are not permitted. In the telephone system, this is managed by controlling the policy applied to an instrument by its switch plus a code produced by the caller identifying himself or herself to the switch. In the Internet, such characteristics must be explicitly signaled. Voice handling characteristics: A call made, in the telephone system, gets a circuit, and provides the means for the callers to conduct their business without significant impact as long as their calls are not preempted. In a VoIP system, one would hope for essentially the same service. Defined User Interface: If a call is preempted, the caller and the callee are notified via a defined signal, so that they know that their call has been preempted and that at this instant there is no alternative circuit available to them at that precedence level. A VoIP implementation of the MLPP service must, by definition, provide those characteristics. 1.5 The use of bandwidth as a solution for QoS There is a discussion in Internet circles concerning the relationship of bandwidth to QoS procedures, which needs to be put to bed before this procedure can be adequately analyzed. The issue is that it is possible and common in certain parts of the Internet to solve the problem with bandwidth. In LAN environments, for example, if there is significant loss between any two switches or between a switch and a server, the simplest and cheapest solution is to buy the next faster interface - substitute 100 MBPS for 10 MBPS Ethernet, 1 Gigabit for 100 MBPS, or for that matter upgrade to a ten gigabit Ethernet. Similarly, in optical networking environments, the simplest and cheapest solution is often to increase the data rate of the optical Baker Expires May 31, 2004 [Page 7] Internet-Draft MLPP for VoIP December 2003 path either by selecting a faster optical carrier or deploying an additional lambda. In places where the bandwidth can be overprovisioned to a point where loss or queuing delay are negligible, 10:1 overprovisioning is often the cheapest and surest solution, and by the way offers a growth path for future requirements. However, there are places in communication networks where bandwidth is not free and is therefore not effectively infinite. It is in these places, and only these places, where the question of resource management is relevant. The places where bandwidth constriction takes place is typically where one pays a significant amount for bandwidth, such as in access paths, or where available technology limits the options. In military networks, Type 1 encryption often presents such a barrier, as do satellite links and various kinds of radio systems. In short, the fact that we are discussing this class of policy control says that such constrictions in the network exist and must be dealt with. Get over it. However much we might like to, in those places we are not solving this with bandwidth. Baker Expires May 31, 2004 [Page 8] Internet-Draft MLPP for VoIP December 2003 2. Solution Proposal A typical Voice or video network, including a backbone domain, is shown in figure 1. ............... ...................... . . . . . H H H H . . H H H H . . /----------/ . . /----------/ . . R SIP . . R R . . \ . . / \ . . R H H H . ....... / \ . . /----------/ .. ../ R SIP . . R .. /. /----------/ . ..... ..\. R-----R . H H H H . ...... .\ / \ . . . \ / \ . . . R-----------R .................... . \ / . . \ / . . R-----R . . . ............ SIP = SIP Proxy H = SIP-enabled Host (Telephone, call gateway or PC) R = Router /---/ = Ethernet or Ethernet Switch Figure 1: Typical VoIP or Video/IP Network Reviewing that figure, it becomes obvious that call flows are very different than call flows in the PSTN. In the PSTN, call control traverses a switch, which in turn controls data handling services like ATM switches or circuit multiplexors. While they may not be physically co-located, the control plane software and the data plane services are closely connected; the switch routes a call using bandwidth that it knows is available. In a voice/video-on-IP network, call control is completely divorced from the data plane: It is possible for a telephone instrument in the United States to have a Swedish telephone number if that is where its SIP proxy happens to be, but on a given call use only data paths in the Asia/Pacific region, data paths provided by a different company, and often multiple companies. Call management therefore addresses a variety of questions, all of which must be answered: o May I make this call from an administrative policy perspective? Baker Expires May 31, 2004 [Page 9] Internet-Draft MLPP for VoIP December 2003 o What IP address correlates with this telephone number or SIP URI? o Is the other instrument "on hook"? If it is busy, under what circumstances may I interrupt? o Is there bandwidth available to support the call? o Does it actually work? 2.1 Call admission/preemption procedure Administrative Call Admission is the objective of SIP and H.323. It asks fundamental questions like "what IP address is the callee at?" and "Did you pay your bill?". For specialized policy like call preemption, two capabilities are necessary from an administrative perspective: "Reason Header Field for the Session Initiation Protocol" [22] provides a reason code when a call fails or is refused, indicating the cause of the event. If it is a failure, it may make sense to redial the call. If it is a policy-driven preemption, even if the call is redialed it may not be possible to place the call. "Communications Resource Priority for the Session Initiation Protocol" [24] provides a way to communicate policy-related information regarding the precedence of the call. This informs both the use of DSCPs by the callee (who needs to use the same DSCP as the caller to obtain the same data path service) and to facilitate policy-based preemption of calls in progress when appropriate. 2.2 Voice handling characteristics The Quality of Service architecture used in the data path is that ofDifferentiated Services [6]. Differentiated Services uses a flag in the IP header called the DSCP [5] to identify a data stream, and then applies a procedure called a Per Hop Behavior, or PHB, to it. In the data path, the Expedited Forwarding [19][20] PHB describes the fundamental needs of voice and video traffic. This PHB entails ensuring that sufficient bandwidth is dedicated to real-time traffic to ensure minimal variation in delay and a minimal loss rate, as codecs are hampered by excessive loss[32][33][34][35][36][37]. In parts of the network where bandwidth is heavily overprovisioned, there may be no remaining concern. In places in the network where bandwidth is more constrained, this may require the use of a priority queue. If a priority queue is used, the potential for abuse exists, meaning that it is also necessary to police traffic placed into the queue to detect and manage abuse. A fundamental question is "where Baker Expires May 31, 2004 [Page 10] Internet-Draft MLPP for VoIP December 2003 does this policing need to take place?". The obvious places would be the first hop routers and any place where converging data streams might congest a link. For policy reasons, DISA would like to mark traffic with various code points marked with code points appropriate to the service level of the call. In normal service, if the traffic is all in the same queue and EF service requirements are met (applied capacity exceeds offered load, variation in delay is minimal, and loss is negligible), details of traffic marking should be irrelevant, as long as they get the packets into the right service class. The question is primarily one of appropriate policing of traffic, especially around route changes. SRTCM [7] or TRTCM [8], in their color-aware modes, can be trivially extended to an arbitrary number of colors given that one knows the bandwidth to be admitted into each service class. Parekh's second condition has been met: we must know what the network will do with the traffic. If the offered load exceeds the available bandwidth, the network will remark and drop the excess traffic. The key questions become "How does one limit offered load to a rate less than or equal to available bandwidth?" and "how much traffic does one admit with each appropriate marking?" 2.3 Bandwidth admission procedure Since the available voice and video codecs require a nominal loss rate to deliver acceptable performance, Parekh's first requirement is that offered load be within the available capacity. There are several possible approaches. 2.3.1 Alternatives that fall short There have been many proposals for measurement-based admission. Fundamentally, these work on the same principle as Keshav's packet-pair algorithm: if a pair of packets or a data stream are added to a stable network data flow, and the result is acceptable, then adding the voice or video data stream is acceptable, and the end system can presume the data flow to have been accepted by the network. While the case can be made in theory for fixed volume data streams, variable data streams such as G.711/G.729 voice with Voice Activity Detection (VAD), the Internet Limited Bandwidth Codec [21], or MPEG-4 video do not work well. These have the property that they can behave benignly for a while, and then change their behavior dramatically. Voice with VAD, for example, may send no data at all for an extended period of time, or only a modicum of comfort noise, and then suddenly jump to life. MPEG-4 will send about 80 KBPS while the camera is pointed at the wall, and jump to 800 KBPS when the camera is pointed at a moving field such as a waving hand. ILBC will Baker Expires May 31, 2004 [Page 11] Internet-Draft MLPP for VoIP December 2003 send at a relatively low bit rate under normal circumstances, but when loss sets in will increase its offered load by as much as 50%. The effect of these is all too predictable with end system measurement-based admission: many data flows will be admitted during periods of lower activity, only to be trashed as a class when activity increases. The most sensible end system behavior in a situation where loss sets in, under end system measurement-based admission, is opt-out admission - the system detecting that it is being adversely affected drops its call. In such a case, however, end systems can be expected to detect the condition - if they detect it at all - in random order, and therefore apply their admission policy randomly, with little real policy control. Many may suddenly detect the condition and drop their calls, resulting in more calls than necessary being lost, and any affected call may be dropped, not just the new ones being added to the mix. One could argue, academically, that a sufficiently complex and randomized opt-out policy could be designed to minimize the issues in this, and maybe one would be right. The fine tuning that would be involved, however, would be extensive, and would not be easily done under combat conditions. An approach that is commonly used in H.323 networks is to limit the number of calls simultaneously accepted by the gatekeeper. SIP networks do something similar when they place a SIP proxy near a single ingress/egress to the network. This is able to impose an upper bound on the total number of call sin the network or the total number of calls crossing the significant link. However, the gatekeeper has no knowledge of routing, so the engineering must be very conservative, and usually requires a single ingress/egress - a single point of failure. While this may serve as a short term work-around, it is not a general solution that is readily deployed. This limits the options in network design. 2.3.2 Recommended procedure: explicit call admission - RSVP Admission using Policy The "Integrated Services in the Internet Architecture: an Overview" [1] provides for signalled admission. This is currently implemented using the "Resource ReSerVation Protocol" [2][4](RSVP). As originally written, RSVP had scaling limitations due to its data plane behavior. This has, in time, largely been corrected. In edge networks, RSVP is used to signal for individual microflows, admitting the bandwidth. However, Differentiated Services is used for the data plane behavior. Admission and policing may be performed anywhere, but need only be performed in the first hop router (which, if the end system sending the traffic is a DTE, constitutes a DCE for the remaining network) and in routers that have interfaces threatened by congestion. In Baker Expires May 31, 2004 [Page 12] Internet-Draft MLPP for VoIP December 2003 figure 1, these would normally be the links that cross network boundaries, and may also include any type 1 encrypted interface, as these are generally limited in bandwidth by the encryption. In backbone networks, networks that are normally awash in bandwidth, RSVP and its affected data flows may be carried in a variety of ways. If the backbone is a maze of tunnels between its edges - true of MPLS networks and of networks that carry traffic from an encryptor to a decryptor, and also of VPNs - applicable technologies include those documents in "RSVP Extensions for IPSEC Data Flows" [3], "RSVP Operation Over IP Tunnels" [9], and "Differentiated Services and Tunnels" [13]. Other networks may simply choose to aggregate the reservations across themselves as described in "Aggregation of RSVP for IPv4 and IPv6 Reservations" [16]. In the PATH message, the DCLASS object described in "Format of the RSVP DCLASS Object" [14] is used to indicate the DSCP that will be used for the data in the stream. This is reflected back in the RESV message. This permits both bandwidth admission within a class and the building up of the various rates or token buckets for the extended color-aware SRTCM or TRTCM algorithm. Policy is carried and applied as described in "A Framework for Policy-based Admission Control" [12]. The "RSVP Extensions for Policy Control" [11], which include the "Signaled Preemption Priority Policy Element" [17] and the "Identity Representation for RSVP" [18], allow for policies which preempt calls under the control of either a local or remote policy manager. The policy manager assigns a precedence level to the admitted data flow. If it admits a data flow that exceeds the available capacity of a system, the expectation is that the RSVP affected RSVP process will tear down a session among the lowest precedence sessions it has admitted. The RESV Error resulting from that will go to the receiver of the data flow, and be reported to the application (SIP or H.323). That application is responsible to disconnect its call, with a reason code of "bandwidth preemption". One will ask the value of the multiple DSCPs. They are, in fact, of limited to no value in normal operation, as all vice and video traffic should have been admitted, and therefore capacity will have been assigned to them. The behavior of this service will be indistinguishable from the EF PHB regardless of traffic marking. However, around route changes - common in manet networks - IP data streams will be shifted around before RSVP admission gets to verify the utility of the new path. While this is normally at most a few seconds, military policy attempts to preserve call quality for more important data flows first. An extended SRTCM or TRTCM, in the color-aware mode, will accomplish this, reducing call quality from lower precedence data flows, while RSVP decides to either admit them Baker Expires May 31, 2004 [Page 13] Internet-Draft MLPP for VoIP December 2003 (changing affected xxTCM quanta) or preempt them. 2.4 Authentication and authorization of calls placed It will be necessary, of course, to ensure that any policy is applied to an authenticated user; it is the capabilities assigned to an authenticated user that may be considered to have been authorized for use in the network. For bandwidth admission, this will require the utilization of "RSVP Cryptographic Authentication" [10][15]. In SIP and H.323, AAA procedures will also be needed. 2.5 Defined User Interface The user interface - the chimes and tones heard by the user - should ideally remain the same as in the MLPP PSTN. This, of course, depends on positive signals, not unreliable measures based on changing measurements. Baker Expires May 31, 2004 [Page 14] Internet-Draft MLPP for VoIP December 2003 3. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Baker Expires May 31, 2004 [Page 15] Internet-Draft MLPP for VoIP December 2003 4. Security Considerations This document outlines a networking capability composed entirely of existing specifications. It has significant security issues, in the sense that a failure of the various authentication or authorization procedures can cause a fundamental breakdown in communications. However, the issues are internal to the various component protocols, and are covered by their various security procedures. Baker Expires May 31, 2004 [Page 16] Internet-Draft MLPP for VoIP December 2003 5. Acknowledgements This document was developed with the knowledge and input of many people, far too numerous to be mentioned by name. Key contributors of thoughts include, however, Francois Le Faucheur, Haluk Keskiner, James Polk, Pete Babendreier, Rohan Mahy, Scott Bradner, Scott Morrison, and Subha Dhesikan. Baker Expires May 31, 2004 [Page 17] Internet-Draft MLPP for VoIP December 2003 References [1] Braden, B., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [2] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [3] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. [4] Braden, B. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997. [5] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [6] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [7] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999. [8] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, September 1999. [9] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. [10] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [11] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. [12] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [13] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [14] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000. Baker Expires May 31, 2004 [Page 18] Internet-Draft MLPP for VoIP December 2003 [15] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001. [16] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [17] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001. [18] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001. [19] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [20] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C. and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002. [21] Andersen, S., "Internet Low Bit Rate Codec", draft-ietf-avt-ilbc-codec-03 (work in progress), October 2003. [22] Oran, D., Schulzrinne, H. and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol", draft-ietf-sip-reason-01 (work in progress), May 2002. [23] Polk, J., "Extending the Session Initiation Protocol Reason Header to account for Preemption Events", draft-polk-sipping-reason-header-for-preemption-00 (work in progress), October 2003. [24] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", draft-ietf-sip-resource-priority-01 (work in progress), July 2003. [25] Pierce, M. and D. Choi, "Architecture for Assured Service Capabilities in Voice over IP", draft-pierce-ieprep-assured-service-arch-01 (work in progress), June 2003. [26] Pierce, M. and D. Choi, "Requirements for Assured Service Baker Expires May 31, 2004 [Page 19] Internet-Draft MLPP for VoIP December 2003 Capabilities in Voice over IP", draft-pierce-ieprep-assured-service-req-01 (work in progress), June 2003. [27] International Telecommunications Union, "Multilevel Precedence and Preemption Service (MLPP)", ITU-T Recommendation I.255.3, 1990. [28] American National Standards Institute, "Telecommunications - Integrated Services Digital Network (ISDN) - Multi-Level Precedence and Preemption (MLPP) Service Capability", ANSI T1.619-1992 (R1999), 1992. [29] American National Standards Institute, "MLPP Service Domain Cause Value Changes", ANSI ANSI T1.619a-1994 (R1999), 1990. [30] Parekh, A. and R. Gallager, "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Multiple Node Case", INFOCOM 1993: 521-530, 1993. [31] Parekh, A. and R. Gallager, "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Single Node Case", INFOCOM 1992: 915-924, 1992. [32] Viola Networks, "Netally VoIP Evaluator", January 2003, . [33] ETSI Tiphon, "ETSI Tiphon Temporary Document 64", July 1999, . [34] Nortel Networks, "Packet Loss and Packet Loss Concealment", 2000, . [35] Clark, A., "Modeling the Effects of Burt Packet Loss and recency on Subjective Voice Quality", 2000, . [36] Cisco Systems, "Understanding Codecs: Complexity, Hardware Support, MOS, and Negotiation", 2003, . [37] Chen, M. and M. Murthi, "On The Performance Of ILBC Over Networks With Bursty Packet Loss", July 2003. Baker Expires May 31, 2004 [Page 20] Internet-Draft MLPP for VoIP December 2003 Author's Address Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com Baker Expires May 31, 2004 [Page 21] Internet-Draft MLPP for VoIP December 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. 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 Baker Expires May 31, 2004 [Page 22] Internet-Draft MLPP for VoIP December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baker Expires May 31, 2004 [Page 23]