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

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/