Internet Engineering Task Force S. Silverman Internet Draft D. Sullivan Category: Experimental Houston Associates draft-silverman-diffserv-mlefphb-03.txt M. Pierce 7 February 2004 Artel Expires: August 2004 Don Choi Defense Information Systems Agency Multi-Level Expedited Forwarding Per Hop Behavior (MLEF PHB) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Copyright notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Some networks require certain packet flows to be transported with preferential treatment over others of the same type. This draft defines a new PHB (Per Hop Behavior), the Multi-Level Expedited Forwarding (MLEF) PHB. RFC 3246 [3] defines the Expedited Forwarding PHB for applications requiring low latency, but with a single DSCP and treatment. This draft extends that concept and defines a PHB with multiple treatments for packet flows for applications requiring low latency and multiple priority levels. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Silverman Expires - Aug. 2004 [Page 1]
Internet-Draft Multi-Level Expedited Forwarding PHB Feb. 2004 Table of Contents 0. Changes from version -02 2 1. Introduction 2 2. Background 3 3 Overview 3 4. Assumptions 4 5. Operation 4 5.1 Required Behavior 4 5.2 Packet Marking 5 5.3 Queue thresholds 5 5.4 Queuing and Discard Operation 7 5.5 Transmitting Procedure 7 5.6 Mathematical Analysis 7 6. Security Considerations 7 7. IANA Considerations 8 8. References 8 9. Author's Addresses 8 A. Annex A: Sample configurations for Priority Services 9 0. Changes from version -02 Section 3, Overview has been modified as a result of online discussions. 1. Introduction This draft 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. RFC 3246 [3] defines "Expedited Forwarding" (EF) using a single queue and requires that packets be dropped if in excess of the "negotiated rate", however, it does not provide for multiple treatments within the single defined class (queue). RFC 2597 [4] defines "Assured Forwarding" (AF) with four classes (queues) and 3 drop treatments within each class, but it is not suitable for voice and does not provide enough distinct treatment levels. This draft 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. Silverman Expires - Aug. 2004 [Page 2]
Internet-Draft Multi-Level Expedited Forwarding PHB Feb. 2004 This draft does not define the application level signaling required to establish the priority packet flow, the accounting that might be required, or security issues that need to be addressed 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. 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. 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 included the MLPP. It allowed authorized users to assign priority to certain calls, and, if there was congestion in the network, higher priority calls got precedence for various resources relative to lower priority calls. In certain existing private circuit-switched networks, some calls within the same network could be preempted by higher priority calls. It is expected that packet-based networks will not require similar preemption of existing packet flows (sessions or calls), since packet techniques provide for significantly better methods of providing the required preferential treatments. 3 Overview EF [3] limited the queue of an output port to a size that would not introduce significant delay or delay variation into a hop by monitoring the queue occupancy and admitting new packets to the queue only if the queue occupancy was below a configured threshold. This resulted in a requirement to drop packets that were in excess of the configured capacity. However, it is based on a single treatment for all packets in the class. Further, EF is based on the presumption that the single EF queue is the first one served, in order to ensure low delay for a packet once placed in this queue. MLEF (patent pending) extends this by making the thresholds for dropping packets a function of the DSCP, which may be based on the priority level of the communication. In order to maintain the guarantee of low delay for queued packets and prevent reordering, it still is 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 priority may be configured for each router supporting this option. MLEF may be viewed as a minor extension of Expedited Forwarding. MLEF does NOT introduce any additional delay to voice packets. Packets are either dropped or enqueued. The amount of computation involved in MLEF processing is not significant. Silverman Expires - Aug. 2004 [Page 3]
Internet-Draft Multi-Level Expedited Forwarding PHB Feb. 2004 Call Admission Control (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 can not do any session layer signaling. The 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. 4. Assumptions It is presumed that MLEF is intended to be used for voice, or other similar constant bit-rate services, which are characterized by relatively steady-state packet rates and sizes. This uniformity eliminates the need for complex dropping algorithms. While the sources are expected to emit packets of fixed sizes, it is expected that any implementation would include a check on the maximum packet size and implement an error procedure for excessively long packets (such as discarding). This necessity is independent from the MLEF operation and would also be necessary in EF to guarantee performance. The description in this draft assumes that the calculation of queue lengths, thresholds, etc. is based on counting packets not bytes. This assumption is made since, when applied to voice, 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 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 [3] did not specify a dropping algorithm, many types of dropping techniques have been described in various references, including: - tail dropping, in which the newly arriving packet is the only one subject to being dropped - random dropping, in which a random packet already in the queue is dropped to make room for the newly arriving packet, such as the Random Early Dropping (RED) referenced in AF [4]. This is necessary to prevent unfair treatment when sources vary widely in packet rate or burstiness. 5. Operation 5.1 Required Behavior As described for AF [4], 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 voice, which is characterized by more steady-state, constant packet rates and sizes, it is not expected that active queue management algorithms would be required. Silverman Expires - Aug. 2004 [Page 4]
Internet-Draft Multi-Level Expedited Forwarding PHB Feb. 2004 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 dropping algorithm, such as to ensure that the same proportion of packets are dropped from each flow in the same drop precedence. Further, it is NOT REQUIRED to provide different drop algorithms for each drop precedence level in the MLEF class. An implementation MAY utilize a more complex discard algorithm, such as RED, similar to those described for AF [4]. 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 precedence. An IP packet that has drop precedence j is marked with the MLEF codepoint MLEFj, where 1 <= j <= M. Within this MLEF class, as the queue fills, packets of the lower priority traffic class are discarded while higher priority traffic is enqueued. This avoids the necessity to dequeue and discard already-queued packets. A DS node MUST NOT reorder MLEF packets. 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 [3], limits MUST be placed on the throughput. This SHOULD be done by calculating the maximum queue length 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 and by discarding packets that would cause this threshold to be exceeded. This maximum is assumed to be calculated based on performance requirements for "normal" traffic, e.g., non-emergency traffic. There is no specific calculation required by this draft, since it is based on various probabilities of required performance parameters. While the actual calculation of MaxQueueSize (maximum queue size for the MLEF queue)is based on probabilities and is not specified by this draft, a working approximation of the value may be obtained by simple calculation from the following: Silverman Expires - Aug. 2004 [Page 5]
Internet-Draft Multi-Level Expedited Forwarding PHB Feb. 2004 AvgPacketSize = average size of all packets placed in the queue. This value is an estimate rather than a dynamically calculated value. Alternatively, if a maximum packet size is enforced, this may be considered in addition to AvgPacketSize in estimating MaxQueueSize. Initial experience has indicated that MaxQueueSize is not a very sensitive number. BW = bandwidth of outgoing interface or less if the one wishes to restrict MLEF traffic to a portion of the available bandwidth MaxDel = maximum delay allowed to be added to packets by this queue MaxQueueSize (in packets) = .75 * BW * MaxDel / AvgPacketSize (The .75 factor is to reserve 25% of the outgoing bandwidth for use by router control.) 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. In addition, for MLEF, individual thresholds for each traffic type using this PHB MUST be determined. Since MaxQueueSize above is calculated for "normal" traffic based on desirable performance and it may be acceptable for emergency or high-priority calls to experience lower performance (greater delay), MaxQueueSize may be increased beyond the normal engineered limits, lowering the probability of packet drops but raising the possible delay for packets in that router, assuming that sufficient storage exists to handle this. These thresholds of percentage of queue fill per drop precedence level are expressed as: MaxQueuePct(j) An implementation would likely convert these percentages to a maximum number of packets for efficient processing, as follows: MaxQueueCnt(j) = MaxQueueSize * MaxQueuePct(j) Further, an implementation MUST maintain a count of the number of packets currently in the queue, or Queue Occupancy Count (QOC), expressed as an integer: QOC Silverman Expires - Aug. 2004 [Page 6]
Internet-Draft Multi-Level Expedited Forwarding PHB Feb. 2004 5.4 Queuing and Discard Operation When a new packet 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. It would also be possible to use a random dropping algorithm, resulting in dropping of a packet already in the queue. However, if such an algorithm is used, it MUST search for a packet of the lowest precedence level to drop. This is thought to be too processing intensive, so is NOT RECOMMENDED. 5.5 Transmitting Procedure Upon serving the MLEF queue, the first packet MUST be dequeued, transmitted, and the QOC value is decremented. 5.6 Mathematical Analysis Since the MLEF PHB only changes 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]. 6. Security Considerations The security considerations of EF [RFC3246] apply unchanged. This draft defines a way of providing preferential treatment to the transport of certain sessions or packet flows. 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 just as with Expedited Forwarding. 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 [5]. This would likely require a trusted edge-router to perform 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 draft. No security measures can be built into the packet transfer within the network core due to the unacceptable overhead that would result. Silverman Expires - Aug. 2004 [Page 7]
Internet-Draft Multi-Level Expedited Forwarding PHB Feb. 2004 7. 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 [6], therefore, there is no action required by IANA. 8. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] 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. [4] Heinanen, J., F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [5] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003. [6] 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. 9. Author's Addresses Steve Silverman 694 Harmony Orchard Rd. Front Royal, VA 22630 Phone: 540 631-0711 Email: steves@shentel.net Dan Sullivan Houston Associates Inc. 4601 N. Fairfax Drive Arlington, VA 22203 Phone:703 284-8837 Email: dsullivan@hai.com Michael Pierce Artel 1893 Preston White Drive Reston, VA 20191 Phone: +1 410.817.4795 Email: pierce1m@ncr.disa.mil Silverman Expires - Aug. 2004 [Page 8]
Internet-Draft Multi-Level Expedited Forwarding PHB Feb. 2004 Don Choi DISA 5600 Columbia Pike Falls Church, VA 22041-2717 Phone: +1 703.681.2312 Email: choid@ncr.disa.mil 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 assigns. This document and the information contained herein is provided as an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 calls and even higher priority to Authorized Emergency calls. The average packet size assumes G.711 and 20 ms samples plus packet overhead. Number of levels = 3 AvgPacketSize = 200 bytes MaxDel = 55 ms Output port speed = 1.544 Mbit/s MaxQueueSize = 40 j DSCP Name MaxQueuePct(j) MaxQueueCnt(j) -------------------------------------------------------- 1 17 Auth. Emergency 100 40 2 9 Emergency 90 36 3 1 Normal 80 32 Silverman Expires - Aug. 2004 [Page 9]
Internet-Draft Multi-Level Expedited Forwarding PHB Feb. 2004 A.2 Sample Configuration for MLPP This is an example of how this PHB could be used to support the MLPP service. It defines 5 priority levels of traffic. The average packet size assumes G.711 and 20 ms samples plus packet overhead. Number of levels = 5 AvgPacketSize = 200 bytes MaxDel = 50 ms Output port speed = 1.544 Mbit/s MaxQueueSize = 36 j DSCP Name MaxQueuePct(j) MaxQueueCnt(j) -------------------------------------------------------- 1 35 Flash Override 100 36 2 27 Flash 90 32.4 3 19 Immediate 80 28.8 4 11 Priority 70 25.2 5 3 Routine 60 21.6 As a practical matter, one can round the queue counts up to an integer to simplify the implementation and speed execution. Silverman Expires - Aug. 2004 [Page 10]