doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc4115.txt b/doc/rfc/rfc4115.txt
new file mode 100644
index 0000000..c1f51d6
--- /dev/null
+++ b/doc/rfc/rfc4115.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                      O. Aboul-Magd
+Request for Comments: 4115                                      S. Rabie
+Category: Informational                                  Nortel Networks
+                                                               July 2005
+
+
+       A Differentiated Service Two-Rate, Three-Color Marker with
+               Efficient Handling of in-Profile Traffic
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+IESG Note
+
+   This RFC is not a candidate for any level of Internet Standard.  The
+   IETF disclaims any knowledge of the fitness of this RFC for any
+   purpose and in particular notes that the decision to publish is not
+   based on IETF review for such things as security, congestion control,
+   or inappropriate interaction with deployed protocols.  The RFC Editor
+   has chosen to publish this document at its discretion.  Readers of
+   this document should exercise caution in evaluating its value for
+   implementation and deployment.  See RFC 3932 for more information.
+
+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.
+
+1.  Introduction
+
+   The differentiated service defines a quality-of-service (QoS)
+   architecture for the Internet [RFC2475].  Two integral components of
+   this architecture are traffic metering and marking.  This document
+   describes a two-rate, three-color metering/marker algorithm that is
+
+
+
+
+
+Aboul-Magd & Rabie           Informational                      [Page 1]
+
+RFC 4115        Efficient Handling of in-Profile Traffic       July 2005
+
+
+   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 [RFC2697]
+   and [RFC2698].  It is different from [RFC2697] in that it is a two-
+   rate, three-color marker.  In contrast, [RFC2697] is a single-rate
+   marker.  It is different from [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 [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 [RFC2698].
+
+2.  Configuration
+
+   The operation of the marker is described by two rate values.  The
+   committed information rate (CIR) and the excess information rate
+   (EIR).  CIR and EIR define 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 the incoming PDU.  The
+   CIR and EIR are both measured in bits/s.  The CIR and EIR can be set
+   independently of each other.  Alternatively, the 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 the rates, CIR and EIR, respectively,
+   and maximum sizes CBS and EBS.
+
+   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 count
+   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).
+
+
+
+
+Aboul-Magd & Rabie           Informational                      [Page 2]
+
+RFC 4115        Efficient Handling of in-Profile Traffic       July 2005
+
+
+   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 described below.
+
+   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.
+
+   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
+   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 from that described in [RFC2698],
+   where traffic is marked green after it passes two conformance tests
+   (those for PIR and CIR).  In either color-blind or color-aware mode,
+   the need to pass two conformance tests could result in packets 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 make
+   yellow traffic starve incoming in-profile green packets.
+
+
+
+
+
+
+
+
+
+
+
+
+Aboul-Magd & Rabie           Informational                      [Page 3]
+
+RFC 4115        Efficient Handling of in-Profile Traffic       July 2005
+
+
+   The operation of the algorithm is illustrated in the flow chart
+   below:
+
+                   +---------------------------------+
+                   |periodically every T sec.        |
+                   | Tc(t+)=MIN(CBS, Tc(t-)+CIR*T)   |
+                   | Te(t+)=MIN(EBS, Te(t-)+EIR*T)   |
+                   +---------------------------------+
+
+          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 |
+                          |    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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboul-Magd & Rabie           Informational                      [Page 4]
+
+RFC 4115        Efficient Handling of in-Profile Traffic       July 2005
+
+
+4.  Service 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 that are green, yellow, or
+   red.  For example, a service may discard all red packets because they
+   exceeded the service rates, forward yellow packets as best effort,
+   and forward green packets with low drop probability.  The marker
+   could also be used for metering L2 VPN services such as the emerging
+   Ethernet transport over IP networks.
+
+5.  Security Considerations
+
+   Security issues resulting from this document are similar to those
+   mentioned in [RFC2697] and [RFC2698].
+
+6.  Informative References
+
+   [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
+             and W. Weiss, "An Architecture for Differentiated Service",
+             RFC 2475, December 1998.
+
+   [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
+             Marker", RFC 2697, September 1999.
+
+   [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
+             Marker", RFC 2698, September 1999.
+
+   [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
+             Procedures", BCP 92, RFC 3932, October 2004.
+
+Authors' Addresses
+
+   Osama Aboul-Magd
+   Nortel Networks
+   3500 Carling Ave
+   Ottawa, ON K2H8E9
+   EMail: osama@nortel.com
+
+   Sameh Rabie
+   Nortel Networks
+   3500 Carling Ave
+   Ottawa, ON K2H8E9
+   EMail: rabie@nortel.com
+
+
+
+
+
+
+
+Aboul-Magd & Rabie           Informational                      [Page 5]
+
+RFC 4115        Efficient Handling of in-Profile Traffic       July 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 at www.rfc-editor.org/copyright.html, and
+   except as set forth therein, the authors retain all their rights.
+
+   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 or 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Aboul-Magd & Rabie           Informational                      [Page 6]
+