--- 1/draft-ietf-pcn-3-in-1-encoding-01.txt 2010-03-09 02:11:02.000000000 +0100 +++ 2/draft-ietf-pcn-3-in-1-encoding-02.txt 2010-03-09 02:11:02.000000000 +0100 @@ -1,19 +1,19 @@ Congestion and Pre-Congestion B. Briscoe Notification T. Moncaster Internet-Draft BT -Intended status: Experimental February 10, 2010 -Expires: August 14, 2010 +Intended status: Experimental March 08, 2010 +Expires: September 9, 2010 PCN 3-State Encoding Extension in a single DSCP - draft-ietf-pcn-3-in-1-encoding-01 + draft-ietf-pcn-3-in-1-encoding-02 Abstract The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. The level of marking allows the boundary nodes to make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to @@ -39,21 +39,21 @@ 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. - This Internet-Draft will expire on August 14, 2010. + This Internet-Draft will expire on September 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -74,42 +74,50 @@ flows. To achieve this, the overall rate of PCN-traffic is metered on every link in the domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. These configured rates are below the rate of the link thus providing notification to boundary nodes about overloads before any congestion occurs (hence "pre-congestion notification"). The level of marking allows boundary nodes to make decisions about whether to admit or terminate. This is achieved by marking packets on interior nodes according to some metering function implemented at - each node. Excess-traffic-marking marks PCN packets that exceed a - certain reference rate on a link while threshold marking marks all - PCN packets on a link when the PCN traffic rate exceeds a higher - reference rate [RFC5670]. These marks are monitored by the egress - nodes of the PCN domain. + each node. Threshold-traffic-marking marks all PCN packets once they + exceed the threshold-traffic-rate on a link while Excess-traffic- + marking marks only those PCN packets that exceed the excess-traffic- + rate, which is higher than the threshold-traffic-rate [RFC5670]. + These marks are monitored by the egress nodes of the PCN domain. To fully support these two types of marking, three encoding states are needed. The baseline encoding described in [RFC5696] provides for deployment scenarios that only require two PCN encoding states using a single Diffserv codepoint. This document describes an experimental extension to the baseline-encoding that adds a third PCN encoding state in the IP header, still using a single Diffserv codepoint. For brevity it will be called the 3-in-1 PCN Encoding. General PCN-related terminology is defined in the PCN architecture [RFC5559], and terminology specific to packet encoding is defined in the PCN baseline encoding [RFC5696]. Note that [RFC5696] requires the PCN Working Group to maintain a list of all DSCPs used for PCN experiments. 1.1. Changes in This Version (to be removed by RFC Editor) + From draft-ietf-pcn-3-in-1-encoding-01 to -02: + + * Corrected mistake in introduction, which wrongly stated that + the threshold-traffic rate is higher than the excess-traffic + rate. Other minor corrections. + + * Updated acks & refs. + From draft-ietf-pcn-3-in-1-encoding-00 to -01: * Altered the wording to make sense if [I-D.ietf-tsvwg-ecn-tunnel] moves to proposed standard. * References updated From draft-briscoe-pcn-3-in-1-encoding-00 to draft-ietf-pcn-3-in-1-encoding-00: @@ -214,26 +221,26 @@ Packets marked NM, ThM or ETM are termed PCN-packets. Their entry into the pcn-domain is controlled by edge nodes that understand how to process PCN markings [RFC5559]. 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding To be compliant with the 3-in-1 PCN Encoding, an PCN interior node behaves as follows: o Except where explicitly stated otherwise, it MUST comply with the - basealine encoding specified in [RFC5696] + baseline encoding specified in [RFC5696] - o It MUST change NM TO ThM if the threshold-meter function indicates + o It MUST change NM to ThM if the threshold-meter function indicates to mark the packet. - o It MUST change NM or ThM TO ETM if the excess-traffic-meter + o It MUST change NM or ThM to ETM if the excess-traffic-meter function indicates to mark the packet. o It MUST NOT change Not-PCN to a PCN-Enabled codepoint and MUST NOT change a PCN-Enabled codepoint to Not-PCN; o It MUST NOT change ThM to NM; o It MUST NOT change ETM to ThM or to NM; In other words, a PCN interior node may increase the severity of @@ -256,37 +263,38 @@ The 3-in-1 PCN Encoding provides three states to encode PCN markings in the ECN field of an IP packet using just one Diffserv codepoint. One state is for not marked packets while the two others are for PCN nodes to mark packets with increasing levels of severity. Use of this encoding presupposes that any tunnels in the PCN region have been updated to comply with [I-D.ietf-tsvwg-ecn-tunnel]. 9. Acknowledgements - Thanks to Phil Eardley for reviewing this. + Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan and Michael Menth for + reviewing this. 10. Comments Solicited To be removed by RFC Editor: Comments and questions are encouraged and very welcome. They can be addressed to the IETF Congestion and Pre-Congestion working group mailing list , and/or to the authors. 11. References 11.1. Normative References [I-D.ietf-tsvwg-ecn-tunnel] Briscoe, B., "Tunnelling of Explicit Congestion - Notification", draft-ietf-tsvwg-ecn-tunnel-03 (work in - progress), July 2009. + Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in + progress), March 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition @@ -299,40 +307,40 @@ [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- Nodes", RFC 5670, November 2009. [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009. 11.2. Informative References [I-D.ietf-pcn-3-state-encoding] - Moncaster, T., Briscoe, B., and M. Menth, "A PCN encoding + Briscoe, B., Moncaster, T., and M. Menth, "A PCN encoding using 2 DSCPs to provide 3 or more states", - draft-ietf-pcn-3-state-encoding-00 (work in progress), - April 2009. + draft-ietf-pcn-3-state-encoding-01 (work in progress), + February 2010. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. Authors' Addresses Bob Briscoe BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK Phone: +44 1473 645196 Email: bob.briscoe@bt.com - URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/ + URI: http://bobbriscoe.net/ Toby Moncaster BT c/o B54/70, Adastral Park Martlesham Heath Ipswich IP5 3RE UK Phone: +44 1206 332805 Email: toby.moncaster@bt.com