idnits 2.16.02
/tmp/draft-heinanen-diffserv-trtcm-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 5 pages
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** The abstract seems to contain references ([RFC2475,RFC2474]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 94: '...easured in bytes and both of them MUST...'
RFC 2119 keyword, line 95: '...r than 0. It is RECOMMENDED that they...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The "Author's Address" (or "Authors' Addresses") section title is
misspelled.
== Couldn't figure out when the document was first submitted -- there may
comments or warnings related to the use of a disclaimer for pre-RFC5378
work that could not be issued because of this. Please check the Legal
Provisions document at https://trustee.ietf.org/license-info to determine
if you need the pre-RFC5378 disclaimer.
-- Couldn't find a document date in the document -- date freshness check
skipped.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: draft-heinanen-diffserv-srtcm has been published as
RFC 2697
-- Possible downref: Normative reference to a draft: ref. 'Heinanen1'
== Outdated reference: draft-ietf-diffserv-af has been published as RFC 2597
-- Possible downref: Normative reference to a draft: ref. 'Heinanen2'
-- Possible downref: Normative reference to a draft: ref. 'Nichols'
** Downref: Normative reference to an Informational RFC: RFC 2475
Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Internet Engineering Task Force Juha Heinanen
2 INTERNET DRAFT Telia Finland
3 Expires November 1999 Roch Guerin
4 University of Pennsylvania
5 May, 1999
7 A Two Rate Three Color Marker
8
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with
13 all provisions of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as Internet-
18 Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet- Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 Distribution of this memo is unlimited.
33 Abstract
35 This document defines a Two Rate Three Color Marker (trTCM), which
36 can be used as a component in a Diffserv traffic conditioner
37 [RFC2475, RFC2474]. The trTCM meters an IP packet stream and marks
38 its packets based on two rates, Peak Information Rate (PIR) and
39 Committed Information Rate (CIR), and their associated burst sizes to
40 be either green, yellow, or red. A packet is marked red if it
41 exceeds the PIR. Otherwise it is marked either yellow or green
42 depending on whether it exceeds or doesn't exceed the CIR.
44 1. Introduction
46 The Two Rate Three Color Marker (trTCM) meters an IP packet stream
47 and marks its packets either green, yellow, or red. A packet is
48 marked red if it exceeds the Peak Information Rate (PIR). Otherwise
49 it is marked either yellow or green depending on whether it exceeds
50 or doesn't exceed the Committed Information Rate (CIR). The trTCM is
51 useful, for example, for ingress policing of a service, where a peak
52 rate needs to be enforced separately from a committed rate.
54 The Meter meters each packet and passes the packet and the metering
55 result to the Marker:
57 +------------+
58 | Result |
59 | V
60 +-------+ +--------+
61 | | | |
62 Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream
63 | | | |
64 +-------+ +--------+
66 The Meter operates in one of two modes. In the Color-Blind mode, the
67 Meter assumes that the packet stream is uncolored. In the Color-
68 Aware mode the Meter assumes that some preceding entity has pre-
69 colored the incoming packet stream so that each packet is either
70 green, yellow, or red. The details of the pre-coloring process,
71 including handling of error scenarios, and how the Meter determines
72 the color of a pre-colored packet are DS domain specific and outside
73 the scope of this document.
75 The Marker (re)colors an IP packet according to the results of the
76 Meter. The color is coded in the DS field [Nichols] of the packet in
77 a PHB specific manner (see section 4 for an example).
79 A companion document [Heinanen1] describes another three color
80 marker, called a Single Rate Three Color Maker (srTCM), where packets
81 are marked based on a single rate and two burst sizes.
83 2. Configuration
85 The trTCM is configured by setting its mode and by assigning values
86 to four traffic parameters: a Peak Information Rate (PIR) and its
87 associated Peak Burst Size (PBS) and a Committed Information Rate
88 (CIR) and its associated Committed Burst Size (CBS).
90 The PIR and CIR are measured in bytes of IP packets per second, i.e.,
91 it includes the IP header, but not link specific headers. The PIR
92 must be equal to or greater than the CIR.
94 The PBS and the CBS and are measured in bytes and both of them MUST
95 be configured to be greater than 0. It is RECOMMENDED that they be
96 configured to be equal to or greater than the size of the largest
97 possible IP packet in the stream.
99 3. Metering
101 The behavior of the Meter is specified in terms of its mode and two
102 token buckets, P and C, with rates PIR and CIR, respectively. The
103 maximum size of the token bucket P is PBS and the maximum size of the
104 token bucket C is CBS.
106 The token buckets P and C are initially (at time 0) full, i.e., the
107 token count Tp(0) = PBS and the token count Tc(0) = CBS. Thereafter,
108 the token count Tp is incremented by one PIR times per second up to
109 PBS and the token count Tc is incremented by one CIR times per second
110 up to CBS.
112 When a packet of size B bytes arrives at time t, the following
113 happens if the trTCM is configured to operate in the Color-Blind
114 mode:
116 o If Tp(t)-B < 0, the packet is red, else
118 o if Tc(t)-B < 0, the packet is yellow and Tp is decremented by B,
119 else
121 o the packet is green and both Tp and Tc are decremented by B.
123 When a packet of size B bytes arrives at time t, the following
124 happens if the trTCM is configured to operate in the Color-Aware
125 mode:
127 o If the packet has been precolored as red or if Tp(t)-B < 0, the
128 packet is red, else
130 o if the packet has been precolored as yellow or if Tc(t)-B < 0,
131 the packet is yellow and Tp is decremented by B, else
133 o the packet is green and both Tp and Tc are decremented by B.
135 The actual implementation of a Meter doesn't need to be modeled
136 according to the above formal specification.
138 4. Marking
140 The Marker reflects the metering result by setting the DS field of
141 the packet to a particular codepoint. In case of the AF PHB
142 [Heinanen2], the color can be coded as the drop precedence of the
143 packet.
145 5. Service Example
147 The trTCM can be used to mark a IP packet stream in a service, where
148 different, decreasing levels of assurances (either absolute or
149 relative) are given to packets which are green, yellow, or red. For
150 example, a service may discard all red packets, because they exceeded
151 the peak rate, forward yellow packets as best effort, and forward
152 green packets with a low drop probability.
154 6. Security Concerns
156 The trTCM has no known security concerns.
158 7. References
160 [Heinanen1] J. Heinanen and R. Guerin, A Single Rate Three Color
161 Marker. Internet draft draft-heinanen-diffserv-srtcm-01.txt, May
162 1999.
164 [Heinanen2] J. Heinanen, et al., Assured Forwarding PHB Group.
165 Internet draft draft-ietf-diffserv-af-06.txt, February 1999.
167 [Nichols] K. Nichols and B. Carpenter, Format for Diffserv Working
168 Group Traffic Conditioner Drafts. Internet draft draft-ietf-diffserv-
169 traffcon-format-00.txt, February 1999.
171 [RFC2474] K. Nichols, et al., Definition of the Differentiated
172 Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474,
173 December 1998.
175 [RFC2475] S. Blake, et al., An Architecture for Differentiated
176 Services. RFC 2475, December 1998.
178 8. Author Addresses
180 Juha Heinanen
181 Telia Finland, Inc.
182 Myyrmaentie 2
183 01600 Vantaa, Finland
184 Email: jh@telia.fi
185 Roch Guerin
186 University of Pennsylvania
187 Department of Electrical Engineering, Rm 367 GRW
188 200 South 33rd Street
189 Philadelphia, PA 19104
190 Email: guerin@ee.upenn.edu