Internet Engineering Task Force Mike Pierce Internet Draft Artel draft-silverman-tsvwg-mlefphb-01.txt Don Choi October 1, 2004 DISA Expires April 1, 2005 Steve Silverman Multi-Level Expedited Forwarding Per Hop Behavior (MLEF PHB) draft-silverman-tsvwg-mlefphb-01.txt Status of this memo By submitting this Internet-Draft, each author certifies that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Copyright Copyright (C) Internet Society 2004. All rights reserved. Reproduction or translation of the complete document, but not of extracts, including this notice, is freely permitted. Abstract Some networks require certain packet flows to be transported with preferential treatment over others of the same type (e.g., voice or video). This document defines a new PHB (Per Hop Behavior), the Multi-Level Expedited Forwarding (MLEF) PHB, which is a minor extension to EF defined in RFC 3246. RFC 3246 defines the Expedited Forwarding PHB for applications requiring low latency, but with a single DSCP and treatment per queue. Although EF suggests that Mike Pierce Expires April 1, 2005 [Page 1] Internet Draft MLEF PHB October 1, 2004 packet discard should be used to achieve this behavior, it does not define an algorithm for packet discard. This document extends that concept and defines a PHB with multiple discard treatments for packet flows for applications requiring low latency and multiple priority levels. Table of Contents 0. Changes from previous version................................2 1. Introduction.................................................3 2. Background...................................................3 3. Overview.....................................................4 3.1. EF Overview.............................................4 3.2. MLEF Overview...........................................4 3.3. Call Admission Control..................................5 4. Assumptions..................................................5 5. Operation....................................................6 5.1. Required Behavior.......................................6 5.2. Packet Marking..........................................6 5.3. Queue Thresholds........................................7 5.4. Queue Occupancy.........................................8 5.5. Queuing and Discard Operation...........................8 5.6. Transmitting Procedure..................................9 6. Mathematical Analysis........................................9 7. Operational Analysis.........................................9 8. Security Considerations.....................................10 9. IANA Considerations.........................................10 10. References..................................................10 10.1. Normative References.................................10 10.2. Informative References...............................10 11. Authors' Addresses..........................................11 0. Changes from previous version This is an update of draft-silverman-tsvwg-mlefphb-00.txt with major changes being in the following areas: - Emphasizes that this is a minor extension to the current EF and only affects the way the decision is made to discard packets. It does not change the queue analysis provided by the EF RFC. - Clarifies that MLEF does not only apply to voice. - Strengthens statement about the reliance on CAC. - Changes calculation of thresholds to eliminate the percentages of queue fill. Instead, maximum delay per priority level is used. - Modified .75 factor (to reserve 25% for router control) to be an adjustable rate to provide for percent of fill of egress reserved for all other classes (router control as well as lower priority classes). Mike Pierce Expires April 1, 2005 [Page 2] Internet Draft MLEF PHB October 1, 2004 - Adds Section 7 on Operational Analysis to explain resulting characteristics of MLEF. - Adds reference to recent IEEE Communications Magazine article. 1. Introduction This document defines an experimental differentiated services (DS) Per Hop Behavior (PHB) to support various application level services which require preferential treatment for packet transfer, such as the Multi-Level Precedence & Preemption function (MLPP) which is required by various organizations in both the US and other countries [I.225.3]. RFC 3246 defines "Expedited Forwarding" (EF) using a single queue and requires that packets be discarded if in excess of the "negotiated rate", however, it does not provide for multiple treatments within the single defined class (queue) nor does it specify the discard procedure. RFC 2597 defines "Assured Forwarding" (AF) with four classes (queues) and three drop treatments within each class, but it is not suitable for voice or other real-time constant bit-rate services and does not provide enough distinct treatment levels. This document extends the EF PHB based on the concepts of AF to provide a single class (queue) but with multiple drop treatments. It retains the notion of "Expedited Forwarding" in order to continue to provide low latency and delay variation. This document does not define the application level signaling required to establish the priority packet flow or the accounting that might be required in conjunction with the use of this PHB. The MLEF PHB defined in this document is not expected to be sufficient, by itself, to deal with periods of congestion during which packets are being discarded. As with EF [RFC3246], MLEF is intended to be a building block for low loss service. In any application, MLEF must be combined with other techniques, such as those which limit new packet flows from being established or which terminate some existing flows in order to alleviate the need for discard. However, just as with EF, there may still be occasions such as unexpectedly high bursts from many inputs in which packets have to be discarded due to buffer fill. 2. Background Some networks are often unable to provision all of the bandwidth that their users need, especially during emergencies. The widespread use of mobile platforms (limiting the use of fiber optic trunks) and the exposure to unexpected loss of resources aggravate this problem. In the circuit-switched environment, application level solutions to this problem include MLPP [I.255.3]]. MLPP allows authorized users to assign a priority to certain calls and, if there is congestion in the network, higher priority calls are given precedence for various resources relative to lower priority calls. In certain existing private circuit-switched networks, some Mike Pierce Expires April 1, 2005 [Page 3] Internet Draft MLEF PHB October 1, 2004 calls within the same network can be preempted by higher priority calls. Preemption is a session layer function and will not be discussed further in this document which deals only with packet layer functions. 3. Overview 3.1. EF Overview The behavior for EF [RFC3246] recommends that strict policing of the use and rate of EF packets be performed at the edge of the DS domain. This limits the traffic to a negotiated rate. Further, the behavior required for EF depends on limiting the depth of the individual queue associated with an egress port to a size that would not introduce significant delay or delay variation into a hop. Although EF by itself does not specify a way to do this, or even require it, it implies that this could be done by Active Queue Management (AQM), thereby monitoring the queue occupancy and admitting new packets to the queue only if the queue occupancy were below a configured threshold. This would result in discarding packets that are in excess of the configured capacity. However, it is based on a common treatment for all packets in the class. Further, EF is based on the presumption that the EF queue is the first one served in order to ensure low delay for a packet once placed in this queue. EF also allows "a Diffserv domain to provide multiple instances of EF", and the text of RFC 3246 implies that multiple EF queues may be used on a single egress. It does not define how they operate or interact. 3.2. MLEF Overview MLEF provides for a minor extension to EF by allowing multiple DSCP values to be combined in one class and making the thresholds for discarding packets a function of the DSCP. The choice of DSCP is presumed to be based on the priority level of the communication. In order to maintain the guarantee of low delay and low delay variation for queued packets and to prevent reordering, MLEF is still based on the use of a single, first-in-first-out queue for all packets. The queue size, the Differentiated Services Code Points (DSCPs) for each priority, and the thresholds for each DSCP may be configured for each egress in a router supporting this option. MLEF does not itself add any additional delay to packets beyond what EF may already cause by queuing. It only affects the packet discard operation. While the overall intention of MLEF, just like EF, is to limit the delay of all packets transported by discarding some, it selectively discards the lower priority packets by applying a lower delay (queue fill) threshold to them while allowing higher delay Mike Pierce Expires April 1, 2005 [Page 4] Internet Draft MLEF PHB October 1, 2004 thresholds for higher priority traffic. Packets are either discarded or enqueued and the maximum delay is a function of the queue size limit (the same as for EF). The amount of computation involved in MLEF processing is not significant. As with EF, MLEF allows the use of multiple instances of MLEF for a single egress, that is, multiple classes (queues). Each MUST be guaranteed a sufficient portion of the output. It is expected that multiple instances of MLEF may be used to support combinations such as voice and video, one in each class. 3.3. Call Admission Control Since MLEF, like EF, only operates on the packet level and is unaware of and unable to control sessions, it cannot prevent congestion. It depends on the existence of higher layer, efficient procedures to limit the establishment of new sessions (packet flows). These procedures are referred to as Call Admission Control (CAC). CAC and MLEF are complimentary rather than mutually exclusive. They operate at different levels and do not interfere with each other, rather, they compensate for each other's deficiencies. As a PHB, MLEF operates at the packet layer. It can operate relatively quickly and can mitigate minor short-term overloads but it cannot do any session layer control or signaling. CAC operates at the session layer and is responsible for overall bandwidth management but, because it may oversee a large area, may not be able to react to short-term fluctuations in bandwidth load and cannot influence the transport of individual packets. 4. Assumptions MLEF is intended to be used for real-time, constant bit-rate services such as voice and video, which are characterized by relatively steady-state packet rates and sizes and the absence of large bursts. This uniformity eliminates the need for complex discard algorithms. While the sources are expected to emit packets of fixed sizes, it is expected that any implementation of MLEF would include a check on the maximum packet size and implement an error procedure for excessively long packets (such as discarding them). This necessity is independent from the MLEF operation and would also be necessary in EF to guarantee performance. The description herein assumes that the calculation of queue lengths, thresholds, etc. is based on counting packets not bytes. This assumption is made since, when applied to constant bit-rate services, it is expected that all packets sharing this queue are roughly the same length. Further, it is expected that packet-based counts and thresholds would allow a more efficient implementation than byte-based counts and thresholds. However, it is equally valid Mike Pierce Expires April 1, 2005 [Page 5] Internet Draft MLEF PHB October 1, 2004 to use byte-based counts and thresholds, as this would have no effect on interoperability. One of the results of these assumptions is that simple tail-dropping is thought to be sufficient. While EF [RFC3246] did not specify a discard algorithm, many types of discard techniques have been described in various references, including: - tail-dropping, in which the newly arriving packet is the only one subject to being discarded - random dropping, in which a random packet already in the queue may be discarded to make room for the newly arriving packet, such as the Random Early Dropping (RED) referenced in AF [RFC2597]. This is necessary to prevent unfair treatment when sources vary widely in packet rate or burstiness. While this PHB assumes simple tail-dropping, it does not exclude the possibility of other, more complex discard algorithms. 5. Operation 5.1. Required Behavior As described for AF [RFC2597], an MLEF implementation SHOULD attempt to minimize long-term congestion within the MLEF class, while allowing short-term congestion resulting from bursts. However, since the purpose of MLEF is to support constant bit-rate services, which are characterized by steady-state, constant packet rates and sizes, it is not expected that active queue management algorithms would be required. In addition, since the individual packet flows are of a constant rate, there does not appear to be any need to apply special procedures to ensure fairness in the discard algorithm, such as to ensure that the same proportion of packets are discarded from each flow in the same drop probability. Further, it is NOT REQUIRED to provide different discard algorithms for each drop probability level in the MLEF class. An implementation MAY utilize a more complex discard algorithm, such as RED, similar to those described for AF [RFC2597 A DS node MUST NOT reorder MLEF packets within one class. 5.2. Packet Marking MLEF provides forwarding of IP packets in a single MLEF class, using a single queue. Within this class, an IP packet is assigned one of M different levels of drop probabilities, which is usually associated with the priority level or importance of the session. An Mike Pierce Expires April 1, 2005 [Page 6] Internet Draft MLEF PHB October 1, 2004 IP packet that has drop probability j is marked with the MLEF codepoint: MLEF(j), where 1 <= j <= M The method by which the source decides how to mark packets is not described. It may be based on a priority level associated with the session establishment. 5.3. Queue Thresholds Just as for EF [RFC3246], limits MUST be placed on the maximum delay introduced by the queue. This SHOULD be done by calculating the maximum queue length for each priority level (drop probability) based on the following: - output interface speed - desired capacity fill on output interface - required overhead and bandwidth reserved for other uses - the queue serving algorithm - the average packet length - the required delay/delay variation performance for each priority level The limits may also be determined empirically by observing actual traffic. Packets SHOULD then be discarded if they would cause this threshold to be exceeded. This maximum is assumed to be calculated based on the desired or acceptable performance requirements for each priority level of traffic. It is based on the notion that a degradation of performance for higher priority traffic is usually preferable to blocking that traffic. There is no specific calculation required herein, since it is based on various probabilities of required performance parameters. While the actual calculation of the maximum queue fill for each priority level within the MLEF PHB queue is based on probabilities and is not specified herein, a working approximation of the values may be obtained by simple calculation from the following: AvgPacketSize = average size of all packets placed in the queue. This value is an estimate rather than a dynamically calculated value. BW = bandwidth of the outgoing interface Rate = percentage of bandwidth of outgoing interface to be guaranteed for use by this MLEF queue (the remainder is used first to service other queues including router control). MaxDel(j) = maximum delay allowed to be added by this queue to packets marked as drop probability j. Mike Pierce Expires April 1, 2005 [Page 7] Internet Draft MLEF PHB October 1, 2004 MaxQueueCnt(j) = BW * Rate * MaxDel(j) / AvgPacketSize As a practical matter, one can round the MaxQueueCnt(j) values to the nearest or next higher integer to simplify the implementation and speed execution. Since MLEF is based on the presumption that higher priority traffic may tolerate higher delays rather than being blocked, the calculation of the thresholds MUST be based on higher MaxDel(j) values for the higher priority traffic. This approximation is used in the examples in Annex A. Note: It needs to be emphasized that this does not represent an absolute maximum size, for example, the memory limit of a buffer holding the queue. It is a probabilistic calculation of the maximum that needs to be observed to meet the performance criteria. It may occasionally be exceeded. 5.4. Queue Occupancy Further, an implementation MUST maintain a count of the number of packets currently in the queue, or: QOC = Queue Occupancy Count Note that this is one count for the entire queue, not one per traffic type in the queue. 5.5. Queuing and Discard Operation Within an MLEF class, as the queue fills, newly arriving packets of the lower priority traffic are discarded while those of the higher priority traffic are enqueued. This avoids the necessity to dequeue and discard already-queued packets. When a new packet marked as drop probability j arrives, the following occurs: If QOC < MaxQueueCnt(j) enqueue packet at end of MLEF queue QOC = QOC + 1 Else discard new packet Endif Note: Simple tail-dropping is assumed here in order to provide the absolute simplest and most efficient implementation. It would also be possible to use a random discard algorithm, possibly resulting in discarding of a packet already in the queue. However, if such an algorithm is used, it MUST search for a packet marked with the highest drop probability. This is thought to be too processing intensive, so is NOT RECOMMENDED. Mike Pierce Expires April 1, 2005 [Page 8] Internet Draft MLEF PHB October 1, 2004 5.6. Transmitting Procedure Upon serving the MLEF queue, the first packet MUST be dequeued, transmitted, and the QOC value is decremented. Although a rate- based serving algorithm appears best, this may operate as a priority queue if the scheduler provides other means to prevent starvation of other queues. 6. Mathematical Analysis Since the MLEF PHB only defines the way in which the decision is made to discard a packet, the analysis of the behavior of packets actually placed into the queue is unchanged from that described in EF [RFC3246]. 7. Operational Analysis In order to provide the basis for comparison with other techniques which may provide a similar preferential treatment, the following can be noted about MLEF: - It does not require extensive configuration parameters. The exact choice of queuing limits per priority level is not important, as long as each level has a limit significantly higher than the next lower level. It is expected that simple tests or experience will determine the appropriate relative limits. - The limits work equally well over a wide range of traffic mixes in the class, from all low priority traffic to a large amount of high priority traffic. In addition, a sudden change in the traffic mix does not require any change in the configuration of the limits, either by human intervention, or by self-adjusting (but possibly time consuming) re-computation. For example, in the case shown in A.2, if the traffic suddenly changes from mostly Routine and some Priority traffic to a situation of mostly Priority and Immediate and some Flash and Flash Override, the already specified limits still provide the performance desired. - When traffic in other classes is not using the egress capacity and the scheduler is able to serve the MLEF queue more often, the MLEF traffic automatically uses the excess without the need to readjust the limits. For example, in the case shown in A.2, during periods in which the other classes are not using the egress bandwidth, the voice MLEF class may utilize more than the guaranteed 40% without modification of any limits shown. - Although the application of MLEF will introduce degraded service (packet loss to lower priority traffic), the effect should be short term since lower priority calls will release, either due to normal release distribution or because the quality has become unusable. An effective CAC should prevent these same or other users from re- originating low priority calls. Mike Pierce Expires April 1, 2005 [Page 9] Internet Draft MLEF PHB October 1, 2004 8. Security Considerations The security considerations of EF [RFC3246] apply unchanged. This document defines a way of providing preferential treatment to the transport of certain sessions or packet flows over others within the same class (queue). Since providing preferential treatment to one user's packets necessarily means that some other user's service may be degraded, some form of security is required so that only authorized users can invoke this capability. The same is true with Expedited Forwarding which is designed to give preferential treatment over traffic in other classes. It is presumed that such security resides at a higher-level application which is being used to establish the packet flow and mark the individual packets, such as SIP [RFC3261]. This would likely require a trusted edge-router to perform or validate the packet marking, with appropriate security measures based on the higher-level application and authentication procedures. However, such security measures are outside the scope of the procedures described in this document. No security measures can be built into the packet transfer within the network core due to the unacceptable overhead that would result. 9. IANA Considerations It is expected that applications of MLEF would use the DSCP values from the range allocated for experimental as defined in RFC 2474, therefore, no action is required by IANA. 10. References 10.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3246] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and Stiliadis, D., "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. 10.2. Informative References [RFC2474] Nichols, K., S. Blake, F. Baker, D. Black, "Definition of the Differentiated Service Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. Mike Pierce Expires April 1, 2005 [Page 10] Internet Draft MLEF PHB October 1, 2004 [RFC2597] Heinanen, J., F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC3261] Rosenberg, J., et al, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3487] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003. [IEEE] "An Investigation of Multilevel Service Provision for Voice over IP Under Catastrophic Congestion", Yang Xu, Martin Westhead, Fred Baker, June 2004 IEEE Communications Magazine. [I.225.3] ITU-T Recommendation I.255.3 "Multilevel Precedence and Preemption (MLPP)" 11. Authors' Addresses Michael Pierce Artel 1893 Preston White Drive Reston, VA 20191 Phone: +1 410.817.4795 Email: pierce1m@ncr.disa.mil Steve Silverman 694 Harmony Orchard Rd. Front Royal, VA 22630 Phone: +1 540.631.0711 Email: steves@shentel.net Don Choi DISA 5600 Columbia Pike Falls Church, VA 22041-2717 Phone: +1 703.681.2312 Email: choid@ncr.disa.mil Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and, except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and the contributor, the organization he/she represents or is sponsored by (if any), the Internet Society, and the Internet Engineering Task Force disclaim all warranties, express or implied, including but not limited to any warranty that the use Mike Pierce Expires April 1, 2005 [Page 11] Internet Draft MLEF PHB October 1, 2004 of the information herein will not infringe any rights or any implied warranties of merchantability or fitness for a particular purpose. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Mike Pierce Expires April 1, 2005 [Page 12] Internet Draft MLEF PHB October 1, 2004 A. Annex A: Sample configurations for Priority Services A.1 Configuration for Emergency Services This is an example of how this PHB could be used to provide higher priority to emergency voice calls (e.g., 911) and even higher priority yet to Authorized Emergency calls. The average packet size assumes G.711 and 20 ms samples plus packet overhead. (The MaxQueueCnt(j) values are rounded to integers.) Number of levels = 3 AvgPacketSize = 200 bytes Output port speed = 1.544 Mbit/s Percentage allocated to this MLEF queue= 60% j DSCP Name MaxDel(j) MaxQueueCnt(j) -------------------------------------------------------- 1 17 Auth. Emergency 20 ms 12 packets 2 9 Emergency 10 6 3 1 Normal 5 3 A.2 Sample Configuration for MLPP This is an example of how this PHB could be used to support the Assured Service (MLPP) capability for voice. It defines five priority levels of voice traffic and guarantees only 40% of the egress to this class in order to reserve sufficient bandwidth for other services in other classes, for example, video. The average packet size assumes G.711 and 20 ms samples plus packet overhead. Number of levels = 5 AvgPacketSize = 200 bytes Output port speed = 1.544 Mbit/s Percentage allocated to this MLEF queue= 40% j DSCP Name MaxDel(j) MaxQueueCnt(j) -------------------------------------------------------- 1 35 Flash-override 30 ms 12 packets 2 27 Flash 25 10 3 19 Immediate 20 8 4 11 Priority 10 4 5 3 Routine 5 2 Mike Pierce Expires April 1, 2005 [Page 13]