WDIFF

draft-aboulmagd-trtcm-inprofile-01.txt --> draft-aboulmagd-trtcm-inprofile-02.txt

Internet Draft Sameh Rabie
Document: draft-aboulmagd-trtcm-inprofile-01.txt
Expires: April 2005
Category: Informational Nortel Networks
October, 2003

November 2004

A Differentiated Service Two Rate Three Color Marker for Differentiated Services Efficient
handling of in-Profile Traffic
draft-aboulmagd-trTCM-inprofile-02.txt

Status of this Memo

By submitting this Internet-Draft, we represent that any applicable
patent or other IPR claims of which we are aware have been disclosed,
or will be disclosed, and any of which we are aware have been or will
be disclosed, and any of which we become aware will be disclosed in
accordance with RFC 3668.

This document is an Internet-Draft and is in full conformance with
all provisions
Sections 5 and 6 of RFC 3667 and Section 10 5 of RFC2026 [1]. RFC 3668.

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.

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

Abstract

This document describes a two rate three color marker that has been
in use for data services including Frame Relay services. This marker
can be used for metering per-flow traffic in the emerging IP and L2
VPN services. The marker defined here is different from previously
defined markers in the handling of the in-profile traffic.
Furthermore this marker doesnÆt impose peak rate shaping
requirements on customer edge (CE) devices.

Aboul-Magd Expires: April 2005 [Page 1]
Internet Draft draft-aboulmagd-trTCM-inprofile-02.txt Nov. 2004

1.
Introduction

The differentiated service defines a quality of service (QoS)
architecture for the Internet [2]. [RFC2475]. Integral component of this
architecture are traffic metering and marking. This document
describes a two rate three color metering/marker algorithm that is
suitable for the differentiated service applications such as IP and
L2 VPNs. This algorithm has been in use for data services including
Frame Relay Service.

The metering/marker defined here is different from those in [3]
[RFC2697] and
[4]. [RFC2698]. It is different from [3] [RFC2697] in that it
is a two-rate, three-color marker. In contrast [3] [RFC2697] is a single
rate marker. It is different

Aboul-Magd Expires April 2004 1
Draft-aboulmagd-trTCM-inprofile-00.txt October 2004 from [4] [RFC2698] in the way its
parameters are defined which allows a better handling of in-profile
traffic for predominant service scenarios over a wider range of
traffic parameters.

Furthermore the algorithm described here eliminates the need for the
CE to shape its traffic to a certain peak information rate (PIR) as
might be the case for the marker defined in [4] [RFC2698] when the value
for the peak burst size (PBS) is smaller than that for the committed
burst size (CBS).

The marker described here operates for both color-blind and color-
aware modes as defined in [4]

3. [RFC2698].

2.
Configuration

The operation of the marker is described by two rate values, those
are the committed information rate (CIR) and the excess information
rate (EIR). Each of CIR and EIR defines the token generation rate of
a token bucket with size that is equal to committed burst size (CBS)
and excess burst size (EBS) respectively.

The CBS and EBS are measured in bytes and must configure to be
greater than the expected maximum length of incoming PDU. Both CIR
and EIR are measured in bits/s. The CIR and EIR can be set
independent of each other. Alternatively CIR and EIR can be linked
together by defining a burst duration parameter T, where
T=CBS/CIR=EBS/EIR.

3.
Metering and Marking

The behavior of the meter is defined in terms of its mode and two
token buckets, C and E, with rate CIR and EIR respectively and
maximum size CBS and EBS.

Aboul-Magd Expires: April 2005 [Page 2]
Internet Draft draft-aboulmagd-trTCM-inprofile-02.txt Nov. 2004

The token buckets C and E are initially (at time 0) full, i.e. the
token count Tc(0) = CBS and Te(0) = EBS. Thereafter the token counts
Tc is incremented by one CIR times per second up to CBS and the
token count Te is incremented by one EIR times per second up to EBS.

In the color aware operation it is assumed that the algorithm can
recognize the color of the incoming packet (Green, yellow, or red).
The color-aware operation of the metering is:

When a green packet of size B arrives at time t, then

o if Tc(t)- B > 0, the packet is green and Tc(t) is decremented by
B, else

o if Te(t)- B > 0, the packet is yellow and Te(t) is decremented by
B, else

o the packet is red

Aboul-Magd Expires April 2004 2
Draft-aboulmagd-trTCM-inprofile-00.txt October 2004

When a yellow packet of size B arrives at time t, then

o if Te(t)- B > 0, the packet is yellow and Te(t) is decremented by
B, else

o the packet is red

Incoming red packets are not tested against any of the two token
buckets and remain red.

In the color blind operation the meter assumes that all incoming
packets are green. The operation of the meter is similar to that in
the color aware operation for green packets.

The salient feature of the algorithm described above is that traffic
that is within the defined CIR is colored green directly without the
need to pass additional conformance tests. This feature is the main
differentiator of this algorithm compared to that described in [4]
[RFC2698] where traffic is marked green after it passes two
conformance tests (those for PIR and CIR). In either color blind or
color aware modes the need to pass two conformance tests could
result in packets been being dropped at the PIR token bucket even though
they are perfectly within their CIR (in-profile traffic).
Furthermore, in the color aware mode of operation, the need to pass
two conformance tests could result in yellow traffic starving
incoming in-profile green packets.

The operation of the algorithm is illustrated in the flow chart
below:

Aboul-Magd Expires: April 2005 [Page 3]
Internet Draft draft-aboulmagd-trTCM-inprofile-02.txt Nov. 2004

Packet of size
B arrives /----------------\
---------------->|color-blind mode|
| OR |YES +---------------+
| green packet |---->|packet is green|
| AND | |Tc(t+)=Tc(t-)-B|
| B <= Tc(t-) | +---------------+
\----------------/
|
| NO
v
/----------------\
|color-blind mode|
| OR |YES +----------------+
| NOT red packet |---->|packet is yellow|
| AND | |Te(t+)=Te(t-)-B |

Aboul-Magd Expires April 2004 3
Draft-aboulmagd-trTCM-inprofile-00.txt October 2004
| B <= Te(t-) | +----------------+
\----------------/
|
| NO
v
+---------------+
|packet is red |
+---------------+

Figure 1: Traffic Metering/Marking Algorithm

In Figure 1, we have X(t-) and X(t+) to indicate the value of a
parameter X right before and right after time t.

4.
Service Scenarios Scenario

The described marker can be used to mark an IP packet stream in a
service, where different, decreasing levels of assurances (either
absolute or relative) are given to packets which are green, yellow,
or red. For example, a service may discard all red packets, because
they exceeded the peak rate, service rates, forward yellow packets as best
effort, and forward green packets with low drop probability. The market
marker could also be used for metering L2 VPN services such as the
emerging Ethernet transport over IP networks.

5.
Security Considerations

The marker/metering algorithm described here has no known security
concerns.

7. References

1 Bradner, S., æThe

Security issues resulting from this document are similar to those
mentioned in RFC[2697] and RFC[2698].

Aboul-Magd Expires: April 2005 [Page 4]
Internet Standards Process -- Revision 3Æ, BCP
9, RFC 2026, October 1996.

2 Blake, S., et. al., æAn Draft draft-aboulmagd-trTCM-inprofile-02.txt Nov. 2004

6.
Informative References

[RFC2475] "An Architecture for Differentiated
ServicesÆ, Service", RFC 2475,
December 1998.

3 Heinanen, J., and Guerin, R., æA

[RFC2697] "A Single Rate Three Color MarkerÆ, Marker", RFC 2697, September
1999.

4 Heinanen, J., and Guerin, R., æA

[RFC2698] "A Two Rate Three Color MarkerÆ, Marker", RFC 2698, September 1999.

8. Author's

7.
Authors' Addresses

Osama Aboul-Magd
Nortel Networks

Aboul-Magd Expires April 2004 4
Draft-aboulmagd-trTCM-inprofile-00.txt October 2004

P.O. Box 3511, Station C
3500 Carling Ave
Ottawa, ONT, Canada
K1Y-4H7
Phone: +1 613 763 5827
E.mail : ON K2H8E9
Email: osama@nortelnetworks.com

Sameh Rabie
Nortel Networks
P.O. Box 3511, Station C
3500 Carling Ave
Ottawa, ONT, Canada
K1Y-4H7
Phone: +1 613 765 2587
E.mail : ON K2H8E9
Email: rabie@nortelnetworks.com

Aboul-Magd Expires Expires: April 2005 [Page 5]
Internet Draft draft-aboulmagd-trTCM-inprofile-02.txt Nov. 2004 5
Draft-aboulmagd-trTCM-inprofile-00.txt October 2004

8.
Full Copyright Statement

"Copyright

Copyright (C) The Internet Society (date). All Rights Reserved. (2004). This document is subject
to the rights, licenses and translations of it may be copied restrictions contained in BCP 78 and furnished to
others,
except as set forth therein, the authors retain all their rights.

This document and derivative works that comment 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 otherwise explain it scope of any
Intellectual Property Rights or assist in its implmentation may other rights that might be prepared, copied, published
and distributed, in whole claimed to
pertain to the implementation or in part, without restriction use of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, technology described in
this document itself may or the extent to which any license under such rights
might or might not be modified in available; nor does it represent that it has
made any independent effort to identify any way, such as by removing rights. Information
on the copyright notice or references procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the Internet Society IETF Secretariat and any
assurances of licenses to be made available, or other
Internet organizations, except as needed for the purpose result of
developing Internet standards in which case the procedures an
attempt made to obtain a general license or permission for
copyrights defined in the Internet Standards process must use of
such proprietary rights by implementers or users of this
specification can be
followed, 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 or as patent applications, or other proprietary
rights that may cover technology that may be required to translate it into. implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Aboul-Magd Expires Expires: April 2004 6 2005 [Page 6]

----