One document matched: draft-silverman-tsvwg-mlefphb-00.txt

Internet Engineering Task Force                                S. Silverman
Internet Draft                                                  D. Sullivan
Category: Experimental                                   Houston Associates
draft-silverman-tsvwg-mlefphb-00.txt                              M. Pierce
6 April 2004                                                          Artel
Expires: October 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 - Oct. 2004                	[Page 1]

Internet-Draft        Multi-Level Expedited Forwarding PHB     April 2004


Table of Contents
0. Changes from previous version 			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 previous version 

This is a minor update of draft-silverman-diffserv-mlefphb-03.txt


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 - Oct. 2004                	[Page 2]

Internet-Draft        Multi-Level Expedited Forwarding PHB     April 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.

Preemption is a session layer function and will not be discussed further in this
draft which deals only with packet layer functions. 



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 - Oct. 2004                	[Page 3]

Internet-Draft        Multi-Level Expedited Forwarding PHB     April 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 - Oct. 2004                	[Page 4]

Internet-Draft        Multi-Level Expedited Forwarding PHB     April 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 - Oct. 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 - Oct. 2004                	[Page 6]

Internet-Draft        Multi-Level Expedited Forwarding PHB     April 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 - Oct. 2004                       	[Page 7]

Internet-Draft        Multi-Level Expedited Forwarding PHB  	   April 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 - Oct. 2004                	[Page 8]

Internet-Draft        Multi-Level Expedited Forwarding PHB     April 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 - Oct. 2004                	[Page 9]

Internet-Draft        Multi-Level Expedited Forwarding PHB     April 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 - Oct. 2004                	[Page 10]