Internet DRAFT - draft-silverman-tsvwg-mlefphb

draft-silverman-tsvwg-mlefphb




Internet Engineering Task Force                        Steve Silverman       
Internet Draft                                         Dan Sullivan     
Expires April 14, 2006                                 Houston Associates 
                                                       Mike Pierce
 						       Oct. 14, 2005
 
      Multi-Level Expedited Forwarding Per Hop Behavior (MLEF PHB) 
                  draft-silverman-tsvwg-mlefphb-03.txt 
 
 
Status of this memo 
 
   By submitting this Internet-Draft, each author represents
   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 Section 6 of BCP 79.
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC 3979. 

   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.

    
   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 2005. 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 
   packet discard should be used to achieve this behavior, it does not 
 
Steve Silverman               Expires April 14, 2006              [Page 1] 
Internet Draft                   MLEF PHB            October 14, 2005 

   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 -00 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 
   A. Sample Configurations for Priority Services...................12 
    
0.   Changes from -00 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). 
    

 
Steve Silverman               Expires April 14, 2006              [Page 2] 
Internet Draft                   MLEF PHB                October 14, 2005 

   - Adds Section 7 on Operational Analysis to explain resulting 
   characteristics of MLEF. 
    
   - Adds reference to recent IEEE Communications Magazine article. 

    Changes from -02 version 
    No major changes from -02.	
 
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 

 
Steve Silverman               Expires April 14, 2006              [Page 3] 
Internet Draft                   MLEF PHB                October 14, 2005 

   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 
 
Steve Silverman               Expires April 14, 2006              [Page 4] 
Internet Draft                   MLEF PHB            October 14, 2005 

   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  
 
Steve Silverman               Expires April 14, 2006              [Page 5] 
Internet Draft                   MLEF PHB            October 14, 2005 

   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 
 
Steve Silverman               Expires April 14, 2006              [Page 6] 
Internet Draft                   MLEF PHB                October 14, 2005 

   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. 
         
 
Steve Silverman               Expires April 14, 2006              [Page 7] 
Internet Draft                   MLEF PHB               October 14, 2005 

        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. 
 

 
Steve Silverman               Expires April 14, 2006              [Page 8] 
Internet Draft                   MLEF PHB               October 14, 2005 

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. 
 
Steve Silverman               Expires April 14, 2006              [Page 9] 
Internet Draft                   MLEF PHB            October 14, 2005 

    
 
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. 
    
 
Steve Silverman               Expires April 14, 2006             [Page 10] 
Internet Draft                   MLEF PHB               October 14, 2005 

   [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)" 
 




   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."
































 
Steve Silverman               Expires April 14, 2006             [Page 11] 
Internet Draft                   MLEF PHB            October 12, 2005 

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 











 
Steve Silverman               Expires April 14, 2006             [Page 12] 
Internet Draft                   MLEF PHB            October 12, 2005 

Authors' Addresses 
 
   
    
   Steve Silverman 
   694 Harmony Orchard Rd. 
   Front Royal, VA 22630 
   Phone: +1 540.631.0711 
   Email: steves@shentel.net 

   Michael Pierce 
   7448 Bradshaw Rd;  
   Kingsville, MD 21087
   Phone: +1 410.817.4795 
   Email: mpierce1@aol.ocm  

   Dan Sullivan
   Houston Associates Inc.
   4601 N. Fairfax Drive
   Arlington, VA 22203  
   Phone:703 284-8837
   Email: dsullivan@hai.com

    
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 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. 
 



 
Steve Silverman               Expires April 14, 2006             [Page 13] 
Internet Draft                   MLEF PHB            October 14, 2005 

Full Copyright Statement 
 
   Copyright (C) The Internet Society (2005).  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. 
    
 















































 
Steve Silverman               Expires August 12, 2005             [Page 14]