One document matched: draft-silverman-diffserv-mlefphb-02.txt

Differences from draft-silverman-diffserv-mlefphb-01.txt

Internet Engineering Task Force                                S. Silverman
Internet Draft                                                  D. Sullivan
Category: Experimental                                   Houston Associates
draft-silverman-diffserv-mlefphb-02.txt                           M. Pierce
(draft) 17 June 2003                                                  Artel
Expires: January 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 [ ]. 

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 (2003).  All Rights Reserved.

Abstract 

Some networks require certain packet flows to be transported with 
greater priority than others.  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, et al	Expires January 2004				[Page 1]



Internet Draft	Multi-Level Expedited Forwarding Per Hop Behavior	July 2003


Table of Contents
0. Changes from version -01	2
1. Introduction	3
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
6. Security Considerations	7
7. IANA Considerations	7
8. References	8
9. Author's Addresses	8
A. Annex A: Sample configurations for Priority Services	9

0. Changes from version -01

1. Restructured based on comments from RFC editor.

2. Terminology (buffer, etc.) changed as suggested by RFC editor. References 
fixed. Term "class" changed to be consistent with AF and EF, that is, one class 
per queue. Multiple priority levels not referred to as multiple "classes".

3. References to maximum packet size and procedures moved to "Assumptions" and 
related to other cases (EF) not just MLEF, so that it doesn't seem to be unique 
to MLEF and therefore a disadvantage.

4. Calculation of the maximum queue size is indicated as an approximation, with 
the actual calculation based on probabilities and not specified.

5. Rounding limit up to an integer deleted to simplify description. Formula 
works fine without this, although an implementation may do it.

6. Explanation of basing thresholds on packet counts instead of byte counts 
clarified.

7. Changed DSCP values in examples to be in experimental set.

Silverman, et al	Expires January 2004				[Page 2]



Internet Draft	Multi-Level Expedited Forwarding Per Hop Behavior	July 2003

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.

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.


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.


Silverman, et al	Expires January 2004				[Page 3]



Internet Draft	Multi-Level Expedited Forwarding Per Hop Behavior	July 2003


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


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, et al	Expires January 2004				[Page 4]



Internet Draft	Multi-Level Expedited Forwarding Per Hop Behavior	July 2003

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.

Silverman, et al	Expires January 2004				[Page 5]



Internet Draft	Multi-Level Expedited Forwarding Per Hop Behavior	July 2003


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:

     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)

Silverman, et al	Expires January 2004				[Page 6]



Internet Draft	Multi-Level Expedited Forwarding Per Hop Behavior	July 2003



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

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.


6. Security Considerations

This draft defines a way of providing preferential treatment to the transport 
of packets to support multiple priority levels for 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.  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, et al	Expires January 2004				[Page 7]



Internet Draft	Multi-Level Expedited Forwarding Per Hop Behavior	July 2003

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, et al	Expires January 2004				[Page 8]



Internet Draft	Multi-Level Expedited Forwarding Per Hop Behavior	July 2003


Don Choi
DISA
5600 Columbia Pike
Falls Church, VA 22041-2717
Phone: +1 703.681.2312
Email: choid@ncr.disa.mil


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


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, et al	Expires January 2004				[Page 9]