Transport Working Group F. Baker Internet-Draft J. Polk Expires: August 15, 2004 Cisco Systems February 15, 2004 Implementing MLPP for Voice and Video in the Internet Protocol Suite draft-baker-tsvwg-mlpp-that-works-01 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 August 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Defense Information Systems Agency of the United States Department of Defense, with its 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 two documents: "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 & Polk Expires August 15, 2004 [Page 1] Internet-Draft MLPP for IP February 2004 Control procedure and a Per Hop Behavior for the data which meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real time sessions. These obviously include but are not limited to Voice and Video applications, although at this writing the community is mostly thinking about Voice on IP and many of the examples in the document are taken from that environment. In a world where a call once permitted is never later refused by the network; only considering setup might be sufficient. However in a network where sessions status can be reviewed by the network and preempted or refused due to changes in routing (when the new routes lack capacity to carry calls switched to them) or changes in offered load (higher precedence calls supercede existing calls), this requires maintaining a continuing model of the status of various calls are using the network. Baker & Polk Expires August 15, 2004 [Page 2] Internet-Draft MLPP for IP February 2004 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Multi-Level Preemption and Precedence . . . . . . . . . . 4 1.2 Definition of Call Admission . . . . . . . . . . . . . . . 6 1.3 Assumptions about the Network . . . . . . . . . . . . . . 7 1.4 Assumptions about application behavior . . . . . . . . . . 7 1.5 Desired Characteristics in an Internet Environment . . . . 8 1.6 The use of bandwidth as a solution for QoS . . . . . . . . 9 2. Solution Proposal . . . . . . . . . . . . . . . . . . . . 11 2.1 Call admission/preemption procedure . . . . . . . . . . . 12 2.2 Voice handling characteristics . . . . . . . . . . . . . . 14 2.3 Bandwidth admission procedure . . . . . . . . . . . . . . 15 2.3.1 Recommended procedure: explicit call admission - RSVP Admission using Policy . . . . . . . . . . . . . . . . . . 15 2.3.2 RSVP Scaling Issues . . . . . . . . . . . . . . . . . . . 17 2.3.3 RSVP Operation in backbones and VPNs . . . . . . . . . . . 17 2.3.4 Interaction with the Differentiated Services Architecture . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.5 Admission policy . . . . . . . . . . . . . . . . . . . . . 19 2.3.5.1 Admission for variable rate codecs . . . . . . . . . . . . 19 2.3.5.2 Interaction with complex admission policies, AAA, and preemption of bandwidth . . . . . . . . . . . . . . . . . 20 2.4 Authentication and authorization of calls placed . . . . . 21 2.5 Defined User Interface . . . . . . . . . . . . . . . . . . 21 3. IANA Considerations . . . . . . . . . . . . . . . . . . . 22 4. Security Considerations . . . . . . . . . . . . . . . . . 23 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 24 References . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . 29 Baker & Polk Expires August 15, 2004 [Page 3] Internet-Draft MLPP for IP February 2004 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: [I-D.pierce-ieprep-assured-service-arch] and [I-D.pierce-ieprep-assured-service-req]. Responding to these are two documents: [I-D.ietf-sipping-reason-header-for-preemption] and [I-D.ietf-sip-resource-priority]. 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. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real time sessions. These obviously include but are not limited to Voice and Video applications, although at this writing the community is mostly thinking about Voice on IP and many of the examples in the document are taken from that environment. In a world where a call once permitted is never later refused by the network; only considering setup might be sufficient. However in a network where sessions status can be reviewed by the network and preempted or refused due to changes in routing (when the new routes lack capacity to carry calls switched to them) or changes in offered load (higher precedence calls supercede existing calls), this requires maintaining a continuing model of the status of various calls are using the network. 1.1 Multi-Level Preemption and Precedence Before doing so, however, let us discuss the problem that MLPP 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 [ITU.MLPP.1990][ANSI.MLPP.Spec][ANSI.MLPP.Supplement], 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. Commanders of combatant commands when declaring Defense Condition One or Defense Emergency or Air Defense Emergency and other Baker & Polk Expires August 15, 2004 [Page 4] Internet-Draft MLPP for IP February 2004 national authorities that the President may authorize in conjunction with Worldwide Secure Voice Conferencing System conferences. Flash Override Override cannot be preempted. Flash 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. Commanders of combatant commands when declaring Defense Condition One or Defense Emergency and other national authorities the President may authorize. Flash Override cannot be preempted in the DSN. 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 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 when congestion occurs within a network. Station based preemption is used when a more important call needs to be placed to either party in an existing call. Trunk based preemption is used when trunk bandwidth needs to be reallocated to facilitate a higher precedence call over a given path in the network. In both Baker & Polk Expires August 15, 2004 [Page 5] Internet-Draft MLPP for IP February 2004 station and trunk based preemption scenarios, preempted parties are positively notified, via preemption tone, that their call can no longer be supported. The same preemption tone is used, regardless of whether calls are terminated for the purposes of station of trunk based preemption. The remainder of this discussion focuses on trunk based preemption issues. 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 an elevated status is not assigned by a user at call initiation time, the call is assumed to be "routine". 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 a utilization threshold, a choice must be made as to which calls to accept or allow to continue. 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) competing with several lower precedence voice calls is a good example of this situation. 1.2 Definition of Call Admission Traditionally, in the PSTN, "Call Admission Control", or CAC, has had the responsibility of determining whether a caller has permission (an identified subscriber, with identify attested to by appropriate credentials, is authorized) to use an available circuit. MLPP, or any emergency telephone service, creates two feedback paths in the algorithm: if a caller is authorized to use a higher precedence, he may also be authorized to use other networks, or the PSTN may be obligated to preempt a call if possible and necessary to create appropriate bandwidth, or it may be authorized to use a guard band of bandwidth that other callers are not. At the completion of CAC, however, the caller either has a circuit that he or she is authorized to use, or has no circuit. Since the act of preemption or consideration of alternative bandwidth sources is part and parcel of the problem of providing bandwidth, and the authorization step in bandwidth provision also affects the choice of networks that may be authorized to be considered. The three cannot be separated. The CAC procedure finds available bandwidth that the caller is authorized to use, and preemption may in some networks be part of making that happen. Baker & Polk Expires August 15, 2004 [Page 6] Internet-Draft MLPP for IP February 2004 1.3 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, often at speeds of 64 KBPS or less. 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, but 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.4 Assumptions about application behavior Parekh and Gallagher published a series of papers [Parekh1][Parekh2] 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 & Polk Expires August 15, 2004 [Page 7] Internet-Draft MLPP for IP February 2004 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 [RFC1633], 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.5 Desired Characteristics in an Internet Environment The key elements of the MLPP service include the following: Baker & Polk Expires August 15, 2004 [Page 8] Internet-Draft MLPP for IP February 2004 Precedence Level Marking each call: Call initiators choose the appropriate precedence level for each call based on user perceived importance of the call. This level is not to be changed for the duration of the call. The call before, and the call after are independent with regard to this level choice. 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 demand 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 call is 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.6 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 Baker & Polk Expires August 15, 2004 [Page 9] Internet-Draft MLPP for IP February 2004 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 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 & Polk Expires August 15, 2004 [Page 10] Internet-Draft MLPP for IP February 2004 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 & Polk Expires August 15, 2004 [Page 11] Internet-Draft MLPP for IP February 2004 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: [I-D.ietf-sip-resource-priority] provides a way to communicate policy-related information regarding the precedence of the call; and [I-D.ietf-sipping-reason-header-for-preemption] 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. The Communications Resource Priority Header (or RP Header) serves the call set-up process with the precedence level chosen by the initiator of the call. The syntax is in the form: Resource Priority : namespace.priority level The "namespace" part of the syntax ensures the domain of significance to the originator of the call, and this travels end-to-end to the destination (called) device (phone). If the receiving phone does not support the namespace, it can easily ignore (what [I-D.ietf-sip-resource-priority] calls "loose mode") or errors (what [I-D.ietf-sip-resource-priority] calls "strict mode") the set-up request. This ability to denote the domain of origin allows SLAs to be in place to limit the ability of an unknown requestor to gain preferential treatment into an MLPP domain. For the DSN infrastructure, this header would look like this: Resource Priority : dsn.routine for a routine precedence level call. The priority level chosen in this header would be compared to the requestor's authorization Baker & Polk Expires August 15, 2004 [Page 12] Internet-Draft MLPP for IP February 2004 profile to user that priority level. This would typically occur in the first hop SIP Proxy server which can challenge many aspects of the call set-up request, including the requestor choice of priority levels (verifying they aren't using a level they are not authorized to use. The DSN has 5 precedence levels of MLPP in descending order: dsn.flash-override dsn.flash dsn.immediate dsn.priority dsn.routine The US Defense Red Switched Network (DRSN), as another example that is to be IANA registered in [I-D.ietf-sip-resource-priority], has 6 levels of precedence. The DRSN simply adds one higher precedence level than flash-override: drsn.flash-override-override to be used by the President and a select few others. Note that the namespace changed for this level. The lower 5 levels within the DRSN would also have this as their namespace for all DRSN originated call set-up requests. 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. Once a call is established in an MLPP domain, the Reason Header for Preemption, described in [I-D.ietf-sipping-reason-header-for-preemption], ensures that all SIP nodes are synchronized to a preemption event occurring either at the endpoint or in a router that experiences congestion. In SIP, the normal indication for the end of a session is for one end system to send a BYE Method request as specified in [RFC3261]. This, too, is the proper means for signaling a termination of a call due to a preemption event, as it essentially performs a normal termination with additional information informing the peer of the reason for the abrupt end - it indicates that a preemption occurred. This will be used to inform all relevant SIP entities, and whether this was a endpoint generated preemption event, or that the preemption event Baker & Polk Expires August 15, 2004 [Page 13] Internet-Draft MLPP for IP February 2004 occurred within a router along the communications path (described in Section 2.3.1 ). 2.2 Voice handling characteristics The Quality of Service architecture used in the data path is that of [RFC2475]. Differentiated Services uses a flag in the IP header called the [RFC2474] to identify a data stream, and then applies a procedure called a Per Hop Behavior, or PHB, to it. This is largely as described in the [RFC2998]. In the data path, the Expedited Forwarding PHB [RFC3246][RFC3247] 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 [G711.1][G711.2][G711.3][G711.4][G711.5][ILBC]. 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 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. The real time voice/video application should be generating traffic at a rate appropriate to its content and codec, which is either a constant bit rate stream or a stream whose rate is variable within a specified range. The first hop router should be policing traffic originated by the application, as is performed in traditional virtual circuit networks like Frame Relay and ATM. Between these two, the application traffic should be guaranteed to be within acceptable limits. As such, given bandwidth-aware call admission control, there should be minimal actual loss. The cases where loss would occur include cases where routing has recently changed and CAC has not caught up, or cases where statistical thresholds are in use in CAC and the data streams happen to coincide at their peak rates. Baker & Polk Expires August 15, 2004 [Page 14] Internet-Draft MLPP for IP February 2004 If it is demonstrated that routing transients and variable rate beat frequencies present a sufficient problem, it is possible to provide a policing mechanism that isolates intentional loss among an ordered set of classes. While the ability to do so, by various algorithms, has been demonstrated, the technical requirement has not. If dropping random packets from all calls is not appropriate, concentrating random loss in a subset of the calls makes the problem for those calls worse; a superior approach would reject or preempt an entire call. 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. 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. The [RFC1633] provides for signalled admission for the use of capacity. This is currently implemented using the Resource Reservation Protocol [RFC2205][RFC2209] (RSVP). The use of Capacity Admission with SIP is described in [RFC3312] ; at this writing, Capacity Admission is not integrated with H.323. 2.3.1 Recommended procedure: explicit call admission - RSVP Admission using Policy RSVP is a resource reservation setup protocol providing the one-way (at a time) setup of resource reservations for multicast and unicast flows. Each reservation is set up in one direction (meaning one Baker & Polk Expires August 15, 2004 [Page 15] Internet-Draft MLPP for IP February 2004 reservation from each end system; in a multicast environment, N senders set up N reservations). These reservations complete a communication path with a deterministic bandwidth allocation through each router along that path between end systems. These reservations setup a known quality of service for end-to-end communications and maintain a "soft-state" within a node. The meaning of the term "soft state" is that in the event of a network outage or change of routing, these reservations are cleared without manual intervention, but must be periodically refreshed. In RSVP, the refresh period is by default 30 seconds, but may be as long as appropriate. RSVP is a local process, not a routing protocol - and uses the local routing databases to determine the path route. RSVP is only concerned with the quality of service for that flow through a device. RSVP is not aware of anything other than the local goal of QoS and its RSVP enabled adjacencies. The process by itself has no end-to-end knowledge. Below is the diagram of RSVP operation in Hosts (end systems) and Routers taken from [RFC2209]. HOST ROUTER _____________________________ ____________________________ | _______ | | | | | | _______ | | _______ | | |Appli- | | | |RSVP | | | | | | cation| | RSVP <---------------------------> RSVP <----------> | | <--> | | | _______ | | | | | | |process| _____ | ||Routing| |process| _____ | | |_._____| | -->Polcy|| || <--> -->Polcy|| | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| | |data | | |_____|| ||__.____| | | |_____|| |===|===========|==|==========| |===|==========|==|==========| | | --------| | _____ | | | --------| | _____ | | | | | ---->Admis|| | | | | ---->Admis|| | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| | | | | | |_____|| | | | | ||_____|| | |Class-| | Packet | | | |Class-| | Packet | | | | ifier|==>Schedulr|================> ifier|==>Schedulr|===========> | |______| |________| |data | |______| |________| |data | | | | |_____________________________| |____________________________| Figure 2: RSVP in Hosts and Routers Figure 2 above shows the internal process of RSVP in both hosts (end systems) and routers. Baker & Polk Expires August 15, 2004 [Page 16] Internet-Draft MLPP for IP February 2004 RSVP uses the phrase "traffic control" to describe the mechanisms of how a data flow receives quality of service. There are 3 different mechanisms to traffic control (shown in Figure 2 in both hosts and routers). They are: A packet classifier mechanism: which resolves the QoS class for each packet; this can determine the route as well. An admission control mechanism: this consists of two decision modules: the admission control module and the policy control module. Determining whether there is satisfactory resources for the requested QoS is the function of admission control. Determining if the user has the authorization to request such resources is the function of policy control. If the parameters carried within this flow fail either of these two modules, RSVP errors the request. A packet scheduler mechanism: at each outbound interface, the scheduler attains the guaranteed QoS for that flow 2.3.2 RSVP Scaling Issues 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 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. 2.3.3 RSVP Operation in backbones and VPNs 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 [RFC2207], [RFC2746], and [RFC2983]. An IP tunnel is simplistically a IP packet enveloped inside another IP packet as a payload. When IPv6 is transported over an IPv4 network, encapsulating the entire v6 packet inside a v4 packet is an effective means to accomplish this task. In this type of tunnel, the IPv6 packet is not read by any of Baker & Polk Expires August 15, 2004 [Page 17] Internet-Draft MLPP for IP February 2004 the routers while inside the IPv4 envelope. If the inner packet is RSVP enabled, there must be a active configuration to ensure that all relevant backbone nodes read the RSVP fields; [RFC2746] describes this. This is similar to how IPsec tunnels work. Encapsulating an RSVP packet inside an encrypted packet for security purposes without copying or conveying the RSVP indicators in the outside IP packet header would make RSVP inoperable while in this form of a tunnel. [RFC2207] describes how to modify an IPsec packet header to allow for RSVP awareness by nodes that need to provide QoS for the flow or flows inside a tunnel. Other networks may simply choose to aggregate the reservations across themselves as described in [RFC3175]. The problem with an individual reservation architecture is that each flow requires a non-trivial amount of message exchange, computation, and memory resources in each router between each endpoint. Aggregation of flows reduces the number of completely individual reservations into groups of individual flows that can act as one for part or all of the journey between end systems. Aggregates are not intended to be from the first router to the last router within a flow, but to cover common paths of a large number of individual flows. Examples of aggregated data flows include streams of IP data that traverse common ingress and egress points in a network, and also include tunnels of various kinds. MPLS LSPs, IPSEC Security Associations between VPN edge routers, similar tunnels between HAIPE encryptors and decryptors, IP/IP tunnels, and GRE tunnels all fall into this general category. The distinguishing factor is that the system injecting an aggregate into the aggregated network sums the PATH and RESV statistical information on the un-aggregated side and produces a reservation for the tunnel on the aggregated side. If the bandwidth for the tunnel cannot be expanded, RSVP leaves the existing reservation in place and returns an error to the aggregator, which can then apply a policy such as MLPP to determine which session to refuse. In the data plane, the DSCP for the traffic must be copied from the inner to the outer header, to preserve the PHB's effect. One concern with this approach is that this leaks information into the aggregated zone concerning the number of active calls or the bandwidth they consume. In fact, it does not, as the data itself is identifiable by aggregator address, deaggregator address, and DSCP. As such, even if it is not advertised, such information is measurable. Baker & Polk Expires August 15, 2004 [Page 18] Internet-Draft MLPP for IP February 2004 2.3.4 Interaction with the Differentiated Services Architecture In the PATH message, the DCLASS object described in [RFC2996] is used to carry the determined DSCP for the precedence level of that call in the stream. This is reflected back in the RESV message. The DSCP will be determined from the authorized SIP message exchange between end systems by using the R-P header. The DCLASS object permits both bandwidth admission within a class and the building up of the various rates or token buckets. 2.3.5 Admission policy RSVP's basic admission policy, as defined, is to grant any user bandwidth if there is bandwidth available within the current configuration. In other words, if a new request arrives and the difference between the configured upper bound and the currently reserved bandwidth is sufficiently large, RSVP grants use of that bandwidth. This basic policy may be augmented in various ways, such as using a local or remote policy engine to apply AAA procedures and further qualify the reservation. 2.3.5.1 Admission for variable rate codecs For certain applications, such as broadcast video using MPEG-1 or voice without activity detection and using a constant bit rate codec such as G.711, this basic policy is adequate apart from AAA. For variable rate codecs, such as MPEG-4 or a voice codec with Voice Activity Detection, however, this may be deemed too conservative. In such cases, two basic types of statistical policy have been studied and reported on in the literature: simple overprovisioning, and approximation to ambient load. Simple overprovisioning sets the bandwidth admission limit higher than the desired load, on the assumption that a session that admits a certain bandwidth will in fact use a fraction of the bandwidth. For example, if MPEG-4 data streams are known to use data rates between 80 and 800 KBPS and there is no obvious reason that sessions would synchronize (such as having commercial breaks on 15 minute boundaries), one could imagine estimating that the average session consumes 400 KBPS and treating an admission of 800 KBPS as actually consuming half the amount. One can also approximate to average load, which is perhaps a more reliable procedure. In this case, one maintains a variable which measures actual traffic through the admitted data's queue, approximating it using an exponentially weighted moving average. When a new reservation request arrives, if the requested rate is less than the difference between the configured upper bound and the current Baker & Polk Expires August 15, 2004 [Page 19] Internet-Draft MLPP for IP February 2004 value of the moving average, the reservation is accepted and the moving average is immediately increased by the amount of the reservation to ensure that the bandwidth is not promised out to several users simultaneously. In time, the moving average will decay from this guard position to an estimate of true load, which may offer a chance to another session to be reserved that would otherwise have been refused. Statistical reservation schemes such as these are overwhelmingly dependent on the correctness of their configuration and its appropriateness for the codecs in use. But they offer the opportunity to take advantage of statistical multiplexing gains that might otherwise be missed. 2.3.5.2 Interaction with complex admission policies, AAA, and preemption of bandwidth Policy is carried and applied as described in [RFC2753]. Figure 3 below is the basic conceptual model for policy decisions and enforcement in an Int-Serv model. This model was created to provide ability to monitor and control reservation flows based on user identify, specific traffic and security requirements and conditions which might change for various reasons, including as a reaction to a disaster or emergency event involving the network or its users. Network Node Policy server ______________ | ______ | | | | | _____ | | PEP | | | |-------------> | |______|<---|------>| PDP |May use LDAP,SNMP,COPS... for accessing | ^ | | | policy database, authentication, etc. | | | |_____|-------------> | __v___ | | | | | PDP = Policy Decision Point | | LPDP | | PEP = Policy Enforcement Point | |______| | LPDP = Local Policy Decision Point |______________| Figure 3: Conceptual Model for Policy Control of Routers The Network Node represents a router in the network. The Policy Server represents the point of admission and policy control by the network operator. Policy Enforcement Point (PEP)(the router) is where the policy action is carried out. Policy decisions can be either locally present in the form of a Local Policy Decision Point (LPDP), or in a separate server on the network called the Policy Decision Baker & Polk Expires August 15, 2004 [Page 20] Internet-Draft MLPP for IP February 2004 Point. The easier the instruction set of rules, the more likely this set can reside in the LDPD for speed of access reasons. The more complex the rule set, the more likely this is active on a remote server. The PDP will use other protocols (LDAP, SNMP, etc) to request information (e.g. user authentication and authorization for precedence level usage) to be used in creating the rule sets of network components. This remote PDP should also be considered where non-reactive policies are distributed out to the LPDPs. Taking the above model as a framework, [RFC2750] extends RSVP's concept of a simple reservation to include policy controls, including the concepts of Preemption [RFC3181] and Identity [RFC3182], specifically speaking to the usage of 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". 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 [RFC2747][RFC3097]. 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 for those indications that are still applicable to an IP network. There should be some new effort generated to update the list of announcements sent to the user which don't necessarily apply. For example, in an end-to-end IP call, there is no known benefit to informing the user which Ethernet switch or router caused the call to fail - as is the equivalent case if a TDM Switch were the cause. All indications to the user, of course, depend on positive signals, not unreliable measures based on changing measurements. Baker & Polk Expires August 15, 2004 [Page 21] Internet-Draft MLPP for IP February 2004 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 & Polk Expires August 15, 2004 [Page 22] Internet-Draft MLPP for IP February 2004 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 & Polk Expires August 15, 2004 [Page 23] Internet-Draft MLPP for IP February 2004 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, Rohan Mahy, Scott Bradner, Scott Morrison, and Subha Dhesikan. Pete Babendreier's review was especially useful. Baker & Polk Expires August 15, 2004 [Page 24] Internet-Draft MLPP for IP February 2004 References [ANSI.MLPP.Spec] American National Standards Institute, "Telecommunications - Integrated Services Digital Network (ISDN) - Multi-Level Precedence and Preemption (MLPP) Service Capability", ANSI T1.619-1992 (R1999), 1992. [ANSI.MLPP.Supplement] American National Standards Institute, "MLPP Service Domain Cause Value Changes", ANSI ANSI T1.619a-1994 (R1999), 1990. [G711.1] Viola Networks, "Netally VoIP Evaluator", January 2003, . [G711.2] ETSI Tiphon, "ETSI Tiphon Temporary Document 64", July 1999, . [G711.3] Nortel Networks, "Packet Loss and Packet Loss Concealment", 2000, . [G711.4] Clark, A., "Modeling the Effects of Burt Packet Loss and recency on Subjective Voice Quality", 2000, . [G711.5] Cisco Systems, "Understanding Codecs: Complexity, Hardware Support, MOS, and Negotiation", 2003, . [I-D.ietf-avt-ilbc-codec] Andersen, S., "Internet Low Bit Rate Codec", draft-ietf-avt-ilbc-codec-04 (work in progress), December 2003. [I-D.ietf-sip-resource-priority] 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. [I-D.ietf-sipping-reason-header-for-preemption] Polk, J., "Extending the Session Initiation Protocol Reason Header for Preemption Events", Baker & Polk Expires August 15, 2004 [Page 25] Internet-Draft MLPP for IP February 2004 draft-ietf-sipping-reason-header-for-preemption-00 (work in progress), January 2004. [I-D.pierce-ieprep-assured-service-arch] Pierce, M. and D. Choi, "Architecture for Assured Service Capabilities in Voice over IP", draft-pierce-ieprep-assured-service-arch-02 (work in progress), January 2004. [I-D.pierce-ieprep-assured-service-req] Pierce, M. and D. Choi, "Requirements for Assured Service Capabilities in Voice over IP", draft-pierce-ieprep-assured-service-req-02 (work in progress), January 2004. [ILBC] Chen, M. and M. Murthi, "On The Performance Of ILBC Over Networks With Bursty Packet Loss", July 2003. [ITU.MLPP.1990] International Telecommunications Union, "Multilevel Precedence and Preemption Service (MLPP)", ITU-T Recommendation I.255.3, 1990. [Parekh1] 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. [Parekh2] 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. [RFC1633] Braden, B., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997. Baker & Polk Expires August 15, 2004 [Page 26] Internet-Draft MLPP for IP February 2004 [RFC2474] 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. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. [RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. [RFC2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000. [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000. [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001. [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001. [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001. Baker & Polk Expires August 15, 2004 [Page 27] Internet-Draft MLPP for IP February 2004 [RFC3246] 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. [RFC3247] 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. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3312] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [RFC3326] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. Authors' Addresses 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 James Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA Phone: +1-469-255-5208 EMail: jmpolk@cisco.com Baker & Polk Expires August 15, 2004 [Page 28] Internet-Draft MLPP for IP February 2004 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 (2004). 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 & Polk Expires August 15, 2004 [Page 29] Internet-Draft MLPP for IP February 2004 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 & Polk Expires August 15, 2004 [Page 30]