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
The list of Internet-Draft Shadow Directories can be accessed at

Copyright notice

Copyright (C) The Internet Society (2004).  All Rights Reserved.


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

"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

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

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

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

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

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:


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


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
         discard new packet

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

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

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

Michael Pierce
1893 Preston White Drive
Reston, VA 20191
Phone: +1 410.817.4795

Silverman             Expires - Aug. 2004                       [Page 8]

Internet-Draft        Multi-Level Expedited Forwarding PHB     Feb. 2004

Don Choi
5600 Columbia Pike
Falls Church, VA 22041-2717
Phone: +1 703.681.2312

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

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

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]