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]
