One document matched: draft-lin-diffserv-gtc-00.txt
Internet Engineering Task Force Longsong Lin
INTERNET DRAFT Jeffrey Lo
Expires October 1999 NEC USA Inc.
Fang-Ching Ou
National Yunlin University
April, 1999
A Generic Traffic Conditioner
<draft-lin-diffserv-gtc-00.txt>
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.
Distribution of this memo is unlimited.
Abstract
This document defines a Generic Traffic Conditioner (GTC) for
Diffserv-capable nodes [RFC2475, RFC2474]. The GTC employs a token
bucket to meter the traffic stream, and uses a shaping buffer to
store out-of-profile packets of a behavior aggregate in order to
enforce conformance to the traffic profile. GTC uses a policer to
decide whether to shape, drop, or re-mark the out-of-profile packets.
The GTC marks each outgoing packet with a Diffserv codepoint (DSCP)
according to the traffic conditioning result in accordance with the
Traffic Conditioning Agreement. By enabling the components and
assigning values to the traffic parameters, it can be applied to
condition the traffic for EF PHB [Jacobson] as well as AF PHB
[Heinanen].
Lin et al. [Page 1]
INTERNET-DRAFT A Generic Traffic Conditioner April 1999
1. Introduction
The Generic Traffic Conditioner (GTC) consists of five functional
components: meter, policer, dropper, marker, and shaper as shown in
Figure 1. The meter measures an IP packet stream and recognizes its
packets to be either in-profile or out-of-profile according to the
traffic profile in the Traffic Conditioning Agreement (TCA). The
meter passes in-profile packets to the marker where a corresponding
DSCP is marked in the packet. The meter could have the in-profile
packets bypass the marker to the forwarding PHB if re-marking is not
necessary. Usually, re-marking takes place at DS boundary node that
connects one DS domain to another DS domain. The meter may pass the
out-of-profile packets to the policer where the decision is made as
to shape, drop or re-mark the packets in accordance with the
provisioning policy in the Traffic Conditioning Agreement. The shaper
stores the out-of-profile packets in a buffer and these packets will
be feedback as an input to the meter for re-metering. The dropper
discards a portion of out-of-profile packets. The marker re-marks a
portion of out-of-profile packets to transform the packets to other
DSCP.
bypass
+---------------+
| |
TR | +-------+ v
| +--->|marker |-----DP-> Marked Packet
v | +-------+ Stream
+-------+ | ^
| |---IN----+ |
| Meter | RM
| | +--------+ |
Packet -AR-->| (TBS) |--OUT->|Policer |-+
Stream +-------+ +--------+
^ | |
| | DR +-------+
| SI +-->|Dropper|
| | +-------+
| +--------+ | |
SBO | | |<--+ v
+--| Shaper | +----------+
| (SBS) |----OF--> \ Discard/
+--------+ \Packet/
\____/
Figure 1. Generic Traffic Conditioner (GTC)
Lin et al. [Page 2]
INTERNET-DRAFT A Generic Traffic Conditioner April 1999
2. Configuration and Monitoring
The GTC is configured by enabling the components and by assigning
values to the three traffic parameters: Token Rate(TR), Token Bucket
Size (TBS), and an Shaping Buffer Size (SBS).
The GTC MAY be configured to serve traffics contracted at different
PHBs. For example, it may function as a TC for EF PHB by enabling a
meter, a policer, a shaper, a dropper, and a marker, i.e., with all
components enabled. Next, it may function as a TC for AF PHB by
enabling a meter, a policer, dropper, a marker, with the
corresponding dropping and re-marking mechanisms in the policer
enabled.
It MUST be possible to monitor the current Token Bucket Occupancy
(TBO), Shaping Buffer Occupancy (SBO), the number of bytes that have
arrived at the shaper per unit time (SI), the in-profile packets in
bytes per unit time (IN), the out-of-profile packets in bytes per
unit time (OUT), the number of bytes of out-of-profile packets that
are dropped per unit time (DR), the number of bytes that have been
re-marked per unit time (RM) and the number of bytes that overflow
the shaping buffer per unit time (OF).
The token rate (TR) is measured in bytes of IP packets per unit time.
It is assumed for simplicity that the unit time be one second and
that all corresponding operations of the components in the GTC MUST
be completed in one unit time. Each packet includes the IP header,
but not link specific headers. The TBS, TBO, SBS and SBO are measured
in bytes.
3. Minimum Functionality
The TBS MUST be configured to be larger than 0 and the SBS MAY be
configured larger than or equal to 0. It is RECOMMENDED that the
value of the TBS or the SBS, if larger than 0, be larger than or
equal to the size of the largest possible IP packet in the stream.
The SBS, if greater than 0, MUST be configured at least larger than
TBS.
The SBS should be configured with respect to the TBS and TR. It is
possible to configure teh SBS as up to two bandwidth-delay products.
However, since shaping often introduces delay for packets being
shaped, it is recommended that the SBS be configured according to the
constraints or requirements of the service being provided and the
delay incurred in shaping buffer should not result in the violation
of these constraints and requirements.
The output of the GTC SHOULD average TR and MUST not exceed TBS+TR
Lin et al. [Page 3]
INTERNET-DRAFT A Generic Traffic Conditioner April 1999
when measured over any time interval equal to or longer than the time
it takes to send an output link MTU sized packet at TR.
4. Algorithm
The behavior of the GTC is specified in terms of two decision-making
functions (metering and policing) and three respective processing
functions (marking, shaping, and dropping). The meter measures the
incoming packets per sampling time and determines which packets are
in-profile and which are out-of-profile. While the in-profile
packets are marked with corresponding DSCP, the out-of-profile
packets are subject to policing. The policer controls each of the
out-of-profile packets, subject them to shaping, re-marking, or
dropping. Out-of-profile packets can be transformed to other classes
of service by re-marking them with a different DSCP; otherwise, they
can be silently discarded by disposing them to a dropper. A
diagrammatic representation of the algorithm is given in Figure 2.
Lin et al. [Page 4]
INTERNET-DRAFT A Generic Traffic Conditioner April 1999
+----------------------------------+
| + - - - - - - - - - - - - - - -|- - - - - - - - - - - - - - - - +
| | V |
| | +---------------------------+ |
| | | DWT(t) = SBO(t-1) + AR(t) | |
| | +---------------------------+ |
| | V |
| | +---------------------------+ |
| | | TAD(t) = TBO(t-1) + TR(t) | |
| | +---------------------------+ |
| | V |
| | No +====================+ Yes |
| | +---------| TAD(t) >= DWT(t) ? |---------+ |
| | V +====================+ V |
| | +------------------------------+ +---------------------+ |
| | | IN(t) <= TAD(t) | | IN(t) = DWT(t) | |
| | |TAD(t) < IN(t)+OUT(t) = DWT(t)| | OUT(t) = 0 | |
| | +------------------------------+ +---------------------+ |
| | | +---------------------------+ | |
| | | | DP(t)= IN(t)+RM(t) | | |
| | +----->| SI(t)= OUT(t)-RM(t)-DR(t) |<----+ |
| | +---------------------------+ |
| + - - - - - - - - - - - | - - - - - - - | - - - - - - - - - - - +
| + - - - - - - - - - - - | - - + + - - -|- - - - - - - - - - - -+
| | Token Buffer | | | | Shaping Buffer |
| | Management V | | V Management |
| | +----------------------+ | | +-------------------+ |
| | | TBO(t)= TAD(t)-IN(t) | | | | SBO= SBO(t)+SI(t) | |
| | +----------------------+ | | +-------------------+ |
| | V | | V |
| | +================+ | | +================+ |
| | | TBO(t) > TBS ? |-----+ | | +------| SBO(t) > SBS ? | |
| | +================+ | | | | +================+ |
| | V Yes No| | | |No V Yes |
| | +------------------+ | | | | +-------------------+ |
| | \ Discard Tokens / | | | | \ Discard Packets / |
| | +--------------+ | | | | +---------------+ |
| | V | | | | V |
| | +--------------+ | | | |+-------------------------+ |
| | | TBO(t) = TBS | | | | ||SBO(t)=SBO(t)+SI(t)-OF(t)| |
| | +--------------+ V | | V+-------------------------+ |
| + - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - -+
| | +----------+
| +------------>| t = t+1 |
| +----|-----+
+----------------------------------+
Figure 2. GTC Algorithm
Lin et al. [Page 5]
INTERNET-DRAFT A Generic Traffic Conditioner April 1999
The token bucket is initially (at time 0) full, i.e., the token
bucket occupancy TBO(0) = TBS, while the shaping buffer is initially
empty, i.e., the shaping buffer occupancy SBO(0) = 0.
The TBO is increased by TR bytes per unit time. Hence the total
available token for the data stream at time t (TAD) is
o TAD(t) = TBO(t) = TBS, for t=0.
o TAD(t) = TBO(t-1)+TR(t), for t>0.
The traffic waiting for tokens in the meter's token bucket come from
two sources: one from the input arrival at the traffic conditioner
(AR) and the other from the feedback from the output of shaping
buffer (SBO), i.e.,
o DWT(t) = AR(t), for t=0.
o DWT(t) = SBO(t-1)+AR(t), for t>0.
To prevent packet reordering, the packets in shaping buffer MUST be
served before any packet arrival to the TC.
If TAD(t) < DWT(t), then the total number of bytes in the packets
that are in-profile (IN) will be IN(t) <= TAD(t), and the total
number of bytes in the packets that are out-of-profile (OUT) should
satisfy TAD(t) < IN(t)+OUT(t) = DWT(t).
If TAD(t) >= DWT(t), then all the packets are in-profile, i.e.
IN(t)=DWT(t) and OUT(t)=0.
OUT(t) in any unit time may be made up of multiple packets. The
policer operates on each of these packets in turn. It decides how
each of the out-of-profile packets is treated depending on its length
and the present occupancy of the sharing buffer. For each out-of-
profile packet i with length Pi,
o If Pi > SBS or Pi > TBS+TR(t), then
drop the packet, DR(t) += Pi,
o else if SBO(t)+SI(t) <= SBS, where SI(t)=Pi, then
shape the packet, SI(t) += Pi,
o else remark the packet, RM(t) += Pi.
Lin et al. [Page 6]
INTERNET-DRAFT A Generic Traffic Conditioner April 1999
+--------------------+
| |
------OUT----->| SUM(Pi) = OUT |
| where 0<= i <=k |
| |
+--------------------+
| Yes
V
+====================+
| |
| Pi |
| >TBS+TR(t) or |------+
| > SBS | |
| | |No
+====================+ |
| V
Drop | +=================+
| | | Remark
| | SBO(t)+SI(t) |-------+
| | <=SBS | |
|Yes | | |
| +=================+ | No
| | |
| Shape |Yes |
V V V
+-----------------++---------------++---------------+
| DR(t) += Pi || SI(t) += Pi || RM(t) += Pi |
+-----------------++---------------++---------------+
| | |
V V V
DR(t) SI(t) RM(t)
Figure 3. Policer
Thereafter, the token bucket and shaping buffer will be updated as
follows.
For IN packets,
o TBO(t) = TAD(t)-IN(t)
o If TBO(t) > TBS,
then discard the extra token and TBO(t) = TBS.
For OUT packets,
o SBO(t) = SBO(t-1) + SI(t), where SI(t)=OUT(t)-RM(t)-DR(t).
o If SBO(t) > SBS, then
discard the overflow packets (OF) and SBO(t) =
SBO(t-1)+SI(t)-OF(t).
Lin et al. [Page 7]
INTERNET-DRAFT A Generic Traffic Conditioner April 1999
5. Remarking
The marker marks the in-profile packets according to traffic profile
defined in the Traffic Conditioning Agreement (TCA). The marker will
distinguish whether or not the current boundary node is a first-hop
router [RFC2475] or an interior node. If it is a first-hop router, it
may be necessary to re-mark the packet to a legitimate codepoint.
The marker also re-marks the packets that are out-of-profile subject
to the disposition policy. Re-marking may result in either change of
PHB group or change of drop preference in a service class. For
example, re-marking may demote the packet from a AF PHB to the
Default best-effort PHB. As another example, re-marking may change
the drop precedence of the packet in AF PHB class [Heinanen]. Re-
marking MUST not cause packet reordering.
6. Example Services
The GTC can be used to serve EF PHB and AF PHB. The GTC conditions
the aggregate via policing and shaping so that its arrival rate (AR)
at any node is always less than that node's configured minimum
departure rate (DP). This property ensures the traffic conditioning
requirement for EF PHB. EF flow packets see sufficient tokens present
will have their EF codepoints mixed.
For the AF PHB, the in-profile packet can be marked as AFx1 and the
out-of-profile packets can be policed to be marked as AFx(2,3),
omitting shaping and dropping.
7. Assumptions
The GTC has no known security concerns and no a priori information
for input traffic.
8. Discussion
The arrangement of the components of the GTC in this document is by
no means the only solution to provide conditioning for diffserv
traffic. A simple configuration for providing a particular purpose is
possible. For example, a meter in front of a marker is sufficient for
delivering AF PHB.
Each component in the GTC can be extended to cover more complex
functions. For example, the meter could output multiple levels of
conformance information, instead of two levels of in or out of
profile information.
Any other components which offer new treatments for out-of-profile
Lin et al. [Page 8]
INTERNET-DRAFT A Generic Traffic Conditioner April 1999
packets can easily be embedded in the GTC as long as it is configured
appropriately. For instance, a spacer can be employed on non-
conforming traffic to reduce the delay variation.
9. References
[Heinanen] J. Heinanen, et al., Assured Forwarding PHB Group.
Internet draft draft-ietf-diffserv-af-06.txt, February 1999.
[Nichols] K. Nichols and B. Carpenter, Format for Diffserv Working
Group Traffic Conditioner Drafts. Internet draft draft-ietf-diffserv-
traffcon-format-00.txt, February 1999.
[RFC2474] K. Nichols, et al., Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474,
December 1998.
[RFC2475] S. Blake, et al., An Architecture for Differentiated
Services. RFC 2475, December 1998.
[Heinanen1] J. Heinanen, et al. A Three Color Marker. Internet draft
draft-heinanen-diffserv-tcm-01.txt, February 1999.
[Jacobson] V.Jacobson, et al., Expedited Forwarding Per Hop Behavior
Internet Draft draft-ietf-diffserv-phb-ef-02.txt, February 1999.
10. Author Address
Longsong Lin
NEC USA, Inc.
110 RIO ROBLES
SAN JOSE, CA 95134, USA
Email : lin@ccrl.sj.nec.com
Tel : (408) 943 3032
Fang-Ching Ou
Dept. of Electronic and Information Engineering
National Yunlin University of Science and Technology
123 University Rd. Section 3, Touliu City, Yunlin, Taiwan
Email : ofcaltos@ms14.hinet.net
Jeffrey Lo
NEC USA, Inc.
110 RIO ROBLES
SAN JOSE, CA 95134, USA
Email : jlo@ccrl.sj.nec.com
Tel : (408) 943 3033
Lin et al. [Page 9]
INTERNET-DRAFT A Generic Traffic Conditioner April 1999
Lin et al. [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 06:35:45 |