draft-ietf-pcn-3-in-1-encoding-03.txt   draft-ietf-pcn-3-in-1-encoding-04.txt 
Congestion and Pre-Congestion B. Briscoe Congestion and Pre-Congestion B. Briscoe
Notification BT Notification BT
Internet-Draft T. Moncaster Internet-Draft T. Moncaster
Intended status: Experimental Independent Intended status: Experimental Moncaster Internet Consulting
Expires: January 13, 2011 M. Menth Expires: July 15, 2011 M. Menth
University of Wuerzburg University of Tuebingen
July 12, 2010 January 11, 2011
Encoding 3 PCN-States in the IP header using a single DSCP Encoding 3 PCN-States in the IP header using a single DSCP
draft-ietf-pcn-3-in-1-encoding-03 draft-ietf-pcn-3-in-1-encoding-04
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.
On every link in the PCN domain, the overall rate of the PCN-traffic On every link in the PCN domain, the overall rate of the PCN-traffic
is metered, and PCN-packets are appropriately marked when certain is metered, and PCN-packets are appropriately marked when certain
configured rates are exceeded. Egress nodes provide decision points configured rates are exceeded. Egress nodes provide decision points
with information about the PCN-marks of PCN-packets which allows them with information about the PCN-marks of PCN-packets which allows them
to take decisions about whether to admit or block a new flow request, to take decisions about whether to admit or block a new flow request,
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 13, 2011. This Internet-Draft will expire on July 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes in This Version (to be removed by RFC Editor) . . 4 1.1. Changes in This Version (to be removed by RFC Editor) . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5 3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5
3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5 3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5
3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6 3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6
3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 6 3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7
4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7 4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7
5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8
6.1. Backward Compatibility with Pre-existing PCN 6.1. Backward Compatibility with Pre-existing PCN
Implementations . . . . . . . . . . . . . . . . . . . . . 8 Implementations . . . . . . . . . . . . . . . . . . . . . 8
6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9 6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9
6.2.1. Use of Both Excess-Traffic-Marking and 6.2.1. Use of Both Excess-Traffic-Marking and
Threshold-Marking . . . . . . . . . . . . . . . . . . 9 Threshold-Marking . . . . . . . . . . . . . . . . . . 9
6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 9 6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 9
6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 9 6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 10 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The objective of Pre-Congestion Notification (PCN) [RFC5559] is to The objective of Pre-Congestion Notification (PCN) [RFC5559] is to
protect the quality of service (QoS) of inelastic flows within a protect the quality of service (QoS) of inelastic flows within a
Diffserv domain, in a simple, scalable, and robust fashion. Two Diffserv domain, in a simple, scalable, and robust fashion. Two
mechanisms are used: admission control, to decide whether to admit or mechanisms are used: admission control, to decide whether to admit or
block a new flow request, and flow termination to decide whether to block a new flow request, and flow termination to terminate some
terminate some already admitted flows during serious pre-congestion. existing flows during serious pre-congestion. To achieve this, the
To achieve this, the overall rate of PCN-traffic is metered on every overall rate of PCN-traffic is metered on every link in the domain,
link in the domain, and PCN-packets are appropriately marked when and PCN-packets are appropriately marked when certain configured
certain configured rates are exceeded. These configured rates are rates are exceeded. These configured rates are below the rate of the
below the rate of the link thus providing notification to boundary link thus providing notification to boundary nodes about overloads
nodes about overloads before any congestion occurs (hence "pre- before any real congestion occurs (hence "pre-congestion
congestion notification"). notification").
Two metering and marking functions are proposed in [RFC5670] that are [RFC5670] provides for two metering and marking functions that are
configured with reference rates. Threshold- marking marks all PCN configured with reference rates. Threshold-marking marks all PCN
packets once their traffic rate on a link exceeds the configured packets once their traffic rate on a link exceeds the configured
reference rate (PCN-threshold-rate). Excess-traffic-marking marks reference rate (PCN-threshold-rate). Excess-traffic-marking marks
only those PCN packets that exceed the configured reference rate only those PCN packets that exceed the configured reference rate
(PCN-excess-rate). The PCN-excess-rate is typically larger than the (PCN-excess-rate). The PCN-excess-rate is typically larger than the
PCN-threshold-rate [RFC5559]. Egress nodes monitor the PCN-marks of PCN-threshold-rate [RFC5559]. Egress nodes monitor the PCN-marks of
received PCN-packets and provide information about the PCN-marks to received PCN-packets and provide information about the PCN-marks to
decision points which take decisions about flow admission and decision points which take decisions about flow admission and
termination on this basis [I-D.ietf-pcn-cl-edge-behaviour], termination on this basis [I-D.ietf-pcn-cl-edge-behaviour],
[I-D.ietf-pcn-sm-edge-behaviour]. [I-D.ietf-pcn-sm-edge-behaviour].
The baseline encoding defined in [RFC5696] describes how two PCN The baseline encoding defined in [RFC5696] describes how two PCN
marking states can be encoded using a single Diffserv codepoint. marking states (Not-marked and PCN-Marked) can be encoded using a
However, to support the application of two different marking single Diffserv codepoint. It also provides an experimental
algorithms in a PCN-domain, for example as required in codepoint (EXP), along with guidelines for use of that codepoint. To
[I-D.ietf-pcn-cl-edge-behaviour], three PCN marking states are support the application of two different marking algorithms in a PCN-
needed. This document describes an extension to the baseline domain, for example as required in [I-D.ietf-pcn-cl-edge-behaviour],
encoding that adds a third PCN marking state in the IP header, still three PCN marking states are needed. This document describes an
using a single Diffserv codepoint. This encoding scheme is called extension to the baseline encoding that uses the EXP codepoint to
ao˛3-in-1 PCN encodingaoˇ. provide a third PCN marking state in the IP header, still using a
single Diffserv codepoint. This encoding scheme is called "3-in-1
All PCN encoding schemes require an additional marking state to PCN encoding".
indicate non-PCN traffic. Therefore, four codepoints are required to
encode three PCN marking states.
This document only concerns the PCN wire protocol encoding for all IP This document only concerns the PCN wire protocol encoding for all IP
headers, whether IPv4 or IPv6. It makes no changes or headers, whether IPv4 or IPv6. It makes no changes or
recommendations concerning algorithms for congestion marking or recommendations concerning algorithms for congestion marking or
congestion response. Other documents define the PCN wire protocol congestion response. Other documents define the PCN wire protocol
for other header types. For example, the MPLS encoding is defined in for other header types. For example, the MPLS encoding is defined in
[RFC5129]. Appendix A provides an informative example for a mapping [RFC5129]. Appendix A provides an informative example for a mapping
between the encodings in IP and in MPLS. between the encodings in IP and in MPLS.
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-03 to -04:
* Updated document to reflect RFC6040.
* Re-wrote introduction.
* Re-wrote section on applicability.
* Re-wrote section on choosing encoding scheme.
* Updated author details.
From draft-ietf-pcn-3-in-1-encoding-02 to -03: From draft-ietf-pcn-3-in-1-encoding-02 to -03:
* Corrected mistakes in introduction and improved overall * Corrected mistakes in introduction and improved overall
readability. readability.
* Added new terminology. * Added new terminology.
* Rewrote a good part of Section 4 and 5 to achieve more clarity. * Rewrote a good part of Section 4 and 5 to achieve more clarity.
* Added appendix explaining when to use which encoding scheme and * Added appendix explaining when to use which encoding scheme and
skipping to change at page 4, line 32 skipping to change at page 4, line 44
* Corrected mistake in introduction, which wrongly stated that * Corrected mistake in introduction, which wrongly stated that
the threshold-traffic rate is higher than the excess-traffic the threshold-traffic rate is higher than the excess-traffic
rate. Other minor corrections. rate. Other minor corrections.
* Updated acks & refs. * 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. draft-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:
* Filename changed to draft-ietf-pcn-3-in-1-encoding. * Filename changed to draft-ietf-pcn-3-in-1-encoding.
* Introduction altered to include new template description of * Introduction altered to include new template description of
PCN. PCN.
skipping to change at page 5, line 25 skipping to change at page 5, line 34
the PCN baseline encoding [RFC5696]. Additional terminology is the PCN baseline encoding [RFC5696]. Additional terminology is
defined below. defined below.
PCN encoding: mapping of PCN marking states to specific codepoints PCN encoding: mapping of PCN marking states to specific codepoints
in the packet header. in the packet header.
3. Requirements for and Applicability of 3-in-1 PCN Encoding 3. Requirements for and Applicability of 3-in-1 PCN Encoding
3.1. PCN Requirements 3.1. PCN Requirements
The PCN architecture [RFC5559] defines that PCN-ingress-nodes of a In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes
PCN-domain control incoming packets. Packets belonging to PCN- control packets entering a PCN-domain. Packets belonging to PCN-
controlled flows are subject to PCN metering and marking, they are controlled flows are subject to PCN-metering and -marking, and PCN-
termed PCN-packets, and PCN-ingress-nodes mark them as not-marked ingress-nodes mark them as Not-marked (PCN-colouring). Any node in
(PCN-colouring). Any node in the PCN-domain may perform PCN metering the PCN-domain may perform PCN-metering and -marking and mark PCN-
and marking and mark PCN-packets if needed. There are two different packets if needed. There are two different metering and marking
metering and marking schemes: threshold-marking and excess-traffic- schemes: threshold-marking and excess-traffic-marking [RFC5670].
marking [RFC5670]. Some edge behaviors require only a single marking Some edge behaviors require only a single marking scheme
scheme [I-D.ietf-pcn-sm-edge-behaviour], others require both [I-D.ietf-pcn-sm-edge-behaviour], others require both
[I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN [I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN
marking states are needed: not-marked (NM) to indicate not-marked marking states are needed: not-marked (NM) to indicate not-marked
packets, threshold-marked (ThM) to indicate packets marked by the packets, threshold-marked (ThM) to indicate packets marked by the
threshold-marker, and excess-traffic-marked (ETM) to indicate packets threshold-marker, and excess-traffic-marked (ETM) to indicate packets
marked by the excess-traffic-marker [RFC5670]. As threshold-marking marked by the excess-traffic-marker [RFC5670]. Threshold-marking and
and excess-traffic-marking start marking packets at different load excess-traffic-marking are configured to start marking packets at
conditions, one marking scheme indicates more severe pre-congestion different load conditions, so one marking scheme indicates more
than the other in terms of higher load. If a packet has been marked severe pre-congestion than the other. Therefore, a fourth PCN
by both a threshold-marker and an excess-traffic-marker, it is marked marking state indicating that a packet is marked by both markers is
with the more severe state. Therefore, a fourth PCN marking state not needed. However a fourth codepoint is required to indicate
indicating that a packet is marked by both markers is not needed. packets that are not PCN-capable (the not-PCN codepoint).
Nonetheless, in addition to codepoints for the three PCN marking
states a fourth codepoint is required to indicate packets that are
not PCN-capable (termed the not-PCN codepoint).
In all current PCN edge behaviors that use two marking schemes In all current PCN edge behaviors that use two marking schemes
[RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking
is configured with a larger reference rate than threshold-marking. is configured with a larger reference rate than threshold-marking.
We take this as a rule and define excess-traffic-marked as a more We take this as a rule and define excess-traffic-marked as a more
severe PCN-mark than threshold-marked. severe PCN-mark than threshold-marked.
3.2. Requirements Imposed by Baseline Encoding 3.2. Requirements Imposed by Baseline Encoding
The baseline encoding scheme [RFC5696] was defined so that it could The baseline encoding scheme [RFC5696] was defined so that it could
skipping to change at page 6, line 29 skipping to change at page 6, line 36
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 1: Structure of the former type-of-service field in IP Figure 1: Structure of the former type-of-service field in IP
Baseline encoding defines that the DSCP must be set to a PCN- Baseline encoding defines that the DSCP must be set to a PCN-
compatible DSCP n and the ECN-field [RFC3168] indicates the specific compatible DSCP n and the ECN-field [RFC3168] indicates the specific
PCN-mark. Baseline encoding offers four possible encoding states PCN-mark. Baseline encoding offers four possible encoding states
within a single DSCP with the following restrictions. within a single DSCP with the following restrictions.
o Codepoint `00' (not-ECT) is used to indicate non-PCN traffic as o Codepoint `00' (not-ECT) is used to indicate non-PCN traffic as
"not-PCN". This allows the use of a DSCP for both PCN and non-PCN "not-PCN". This allows both PCN and non-PCN traffic to use the
traffic. same DSCP.
o Codepoint `10' (ECT(0)) is used to indicate Not-marked PCN o Codepoint `10' (ECT(0)) is used to indicate Not-marked PCN
traffic. traffic.
o Codepoint `11' (CE) is used to indicate the most severe PCN-mark. o Codepoint `11' (CE) is used to indicate the most severe PCN-mark.
o Codepoint `01' (ECT(1)) is available for experimental use and may o Codepoint `01' (ECT(1)) is available for experimental use and may
be re-used by other PCN encodings such as the presently defined be re-used by other PCN encodings such as the presently defined
3-in-1 PCN encoding. 3-in-1 PCN encoding (subject to the rules defined in [RFC5696]).
3.3. Applicability of 3-in-1 PCN Encoding [RFC6040] defines rules for the encapsulation and decapsulation of
ECN markings within IP-in-IP tunnels. This RFC removes some of the
constraints that existed when [RFC5696] was written. Happily the
rules for use of the EXP codepoint are fully compatible with
When PCN traffic is tunneled IP-in-IP within a PCN-domain, PCN-marks [RFC6040]. In particular, the relative severity of each marking is
must be preserved in all outer IP headers after encapsulation and the same: CE (PM) is more severe than ECT(1) (EXP) is more severe
decapsulation. This property is violated by legacy encapsulation and than ECT(0) (NM). This is discussed in more detail in both the
decapsulation rules [RFC3168], [RFC4301] due to the way they treat baseline encoding document [RFC5696] and in
the ECN field. This led to strong limitations regarding how PCN- [I-D.ietf-pcn-encoding-comparison].
marks can be encoded using the ECN field of the IP header
[I-D.ietf-pcn-encoding-comparison]. Therefore, baseline encoding
[RFC5696] was defined which works well with legacy tunnels but
supports only two PCN marking states.
Since then, new rules have been defined for IP-in-IP tunneling 3.3. Applicability of 3-in-1 PCN Encoding
[I-D.ietf-tsvwg-ecn-tunnel] so that the present 3-in-1 PCN encoding
has more freedom to accommodate PCN-marks using the ECN field. From The 3-in-1 encoding is applicable in situations where two marking
this follows that 3-in-1 PCN encoding may be applied only in PCN- schemes are being used in the PCN-domain. In some circumstances it
domains that comply with [I-D.ietf-tsvwg-ecn-tunnel] or do not use can also be used in PCN-domains with only a single marking scheme in
tunneling. use. Further guidance on choosing an encoding scheme can be found in
Section 6.2. All nodes within the PCN-domain MUST be fully compliant
with the ECN encapsulation rules set out in [RFC6040]. As such the
encoding is not applicable in situations where legacy tunnels might
exist.
4. Definition of 3-in-1 PCN Encoding 4. Definition of 3-in-1 PCN Encoding
The 3-in-1 PCN encoding scheme is an extension of the baseline The 3-in-1 PCN encoding scheme is an extension of the baseline
encoding scheme defined in [RFC5696]. The PCN requirements and the encoding scheme defined in [RFC5696]. The PCN requirements and the
extension rules for baseline encoding presented in the previous extension rules for baseline encoding presented in the previous
section determine how PCN encoding states are carried in the IP section determine how PCN encoding states are carried in the IP
headers. This is shown in Figure 2. headers. This is shown in Figure 2.
+--------+----------------------------------------------------+ +--------+----------------------------------------------------+
| | Codepoint in ECN field of IP header | | | Codepoint in ECN field of IP header |
| DSCP | <RFC3168 codepoint name> | | DSCP | <RFC3168 codepoint name> |
| +--------------+-------------+-------------+---------+ | +--------------+-------------+-------------+---------+
| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> | | | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
+--------+--------------+-------------+-------------+---------+ +--------+--------------+-------------+-------------+---------+
| DSCP n | Not-PCN | NM | ThM | ETM | | DSCP n | Not-PCN | NM | ThM | ETM |
+--------+--------------+-------------+-------------+---------+ +--------+--------------+-------------+-------------+---------+
Figure 2: 3-in-1 PCN Encoding Figure 2: 3-in-1 PCN Encoding
skipping to change at page 8, line 6 skipping to change at page 8, line 17
ETM: Excess-traffic-marked. Indicates a PCN-packet that has been ETM: Excess-traffic-marked. Indicates a PCN-packet that has been
marked by an excess-traffic-marker [RFC5670]. marked by an excess-traffic-marker [RFC5670].
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 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. a need 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 a need to mark the packet;
o It MUST NOT change not-PCN to NM, ThM, or ETM, and MUST NOT change o It MUST NOT change not-PCN to NM, ThM, or ETM;
a NM, ThM, or ETM to not-PCN;
o It MUST NOT change a NM, ThM, or ETM 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 MUST NOT mark PCN-packets into In other words, a PCN interior node MUST NOT mark PCN-packets into
non-PCN packets and vice-versa, and it may increase the severity of non-PCN packets and vice-versa, and it may increase the severity of
the PCN-mark of a PCN-packet, but it MUST NOT decrease it. the PCN-mark of a PCN-packet, but it MUST NOT decrease it.
6. Backward Compatibility 6. Backward Compatibility
skipping to change at page 8, line 47 skipping to change at page 9, line 12
of such domains are required to interpret the full 3-in-1 encoding of such domains are required to interpret the full 3-in-1 encoding
and not just baseline encoding, otherwise they cannot interpret the and not just baseline encoding, otherwise they cannot interpret the
01 codepoint. 01 codepoint.
Using nodes that perform only excess-traffic-marking may make sense Using nodes that perform only excess-traffic-marking may make sense
in networks using the CL edge behavior in networks using the CL edge behavior
[I-D.ietf-pcn-cl-edge-behaviour]. Such nodes are able to notify the [I-D.ietf-pcn-cl-edge-behaviour]. Such nodes are able to notify the
egress only about severe pre-congestion when traffic needs to be egress only about severe pre-congestion when traffic needs to be
terminated. This seems reasonable for locations that are not terminated. This seems reasonable for locations that are not
expected to see any pre-congestion, but excess-traffic-marking gives expected to see any pre-congestion, but excess-traffic-marking gives
them a means to terminate traffic if unexpected overload still them a means to terminate traffic if unexpected overload occurs.
occurs.
6.2. Recommendations for the Use of PCN Encoding Schemes 6.2. Recommendations for the Use of PCN Encoding Schemes
This sub-section is informative not normative. NOTE: This sub-section is informative not normative.
+------------------------+------------------------------------+
| Used marking schemes | Recommended PCN encoding scheme |
+------------------------+------------------------------------+
| Only threshold-marking | Baseline encoding [RFC5696] |
+------------------------+------------------------------------+
| Only excess-traffic- | Baseline encoding [RFC5696] |
| marking | or 3-in-1 PCN encoding |
+------------------------+------------------------------------+
| Threshold-marking and | 3-in-1 PCN encoding |
| excess-traffic-marking | |
+------------------------+------------------------------------+
Figure 3: Use of PCN encoding schemes When deciding which PCN encoding is suitable an operator needs to
take account of how many PCN states need to be encoded. The
following table gives guidelines on which encoding to use with either
threshold-marking, excess-traffic marking or both.
Figure 3 gives guidelines under which conditions baseline encoding +------------------------+--------------------------------+
and 3-in-1 PCN encoding would typically be used. | Used marking schemes | Recommended encoding scheme |
+------------------------+--------------------------------+
| Only threshold-marking | Baseline encoding [RFC5696] |
+------------------------+--------------------------------+
| Only excess-traffic- | Baseline encoding [RFC5696] |
| marking | or 3-in-1 PCN encoding |
+------------------------+--------------------------------+
| Threshold-marking and | 3-in-1 PCN encoding |
| excess-traffic-marking | |
+------------------------+--------------------------------+
Figure 3: Guidelines for choosing PCN encoding schemes
6.2.1. Use of Both Excess-Traffic-Marking and Threshold-Marking 6.2.1. Use of Both Excess-Traffic-Marking and Threshold-Marking
If both excess-traffic-marking and threshold-marking are enabled in a If both excess-traffic-marking and threshold-marking are enabled in a
PCN-domain, 3-in-1 encoding should be used as described in this PCN-domain, 3-in-1 encoding should be used as described in this
document. document.
6.2.2. Unique Use of Excess-Traffic-Marking 6.2.2. Unique Use of Excess-Traffic-Marking
If only excess-traffic-marking is enabled in a PCN-domain, baseline If only excess-traffic-marking is enabled in a PCN-domain, baseline
encoding or 3-in-1 encoding may be used. They lead to the same encoding or 3-in-1 encoding may be used. They lead to the same
encoding because PCN-boundary nodes will interpret baseline "PCN- encoding because PCN-boundary nodes will interpret baseline "PCN-
marked (PM)" as "excess-traffic-marked (ETM)". marked (PM)" as "excess-traffic-marked (ETM)".
6.2.3. Unique Use of Threshold-Marking 6.2.3. Unique Use of Threshold-Marking
No scheme is currently proposed to solely use threshold-marking. No scheme is currently proposed that solely uses threshold-marking.
However, if only threshold-marking is enabled in a PCN-domain, If such a scheme is proposed, the choice of encoding scheme will
baseline encoding SHOULD be used. This is because threshold marking depend on whether nodes are compliant with [RFC6040] or not. Where
will work in combination with legacy tunnel decapsulators within the it is certain that all nodes in the PCN-domain are compliant then
PCN-domain, while using threshold marking with the 3-in-1 encoding either 3-in-1 encoding or baseline encoding are suitable. If legacy
requires that tunnel decapsulators within a PCN-domain comply with tunnel decapsulators exist within the PCN-domain then baseline
[I-D.ietf-tsvwg-ecn-tunnel]. encoding SHOULD be used.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
8. Security Considerations 8. Security Considerations
skipping to change at page 10, line 30 skipping to change at page 10, line 44
security issues are raised, as this codepoint was already available security issues are raised, as this codepoint was already available
for experimental use in the baseline encoding. for experimental use in the baseline encoding.
9. Conclusions 9. Conclusions
The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field
to encode PCN-marks. One codepoint allows non-PCN traffic to be to encode PCN-marks. One codepoint allows non-PCN traffic to be
carried with the same PCN-compatible DSCP and three other codepoints carried with the same PCN-compatible DSCP and three other codepoints
support three PCN marking states with different levels of severity. support three PCN marking states with different levels of severity.
The use of this PCN encoding scheme presupposes that any tunnels in The use of this PCN encoding scheme presupposes that any tunnels in
the PCN region have been updated to comply with the PCN region have been updated to comply with [RFC6040].
[I-D.ietf-tsvwg-ecn-tunnel].
10. Acknowledgements 10. Acknowledgements
Thanks to Phil Eardley, Teco Boot, and Kwok Ho Chan for reviewing Thanks to Phil Eardley, Teco Boot, and Kwok Ho Chan for reviewing
this document. this document.
11. Comments Solicited 11. 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
skipping to change at page 11, line 34 skipping to change at page 11, line 45
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009. Architecture", RFC 5559, June 2009.
[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.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010.
12.2. Informative References 12.2. Informative References
[I-D.ietf-pcn-cl-edge-behaviour] [I-D.ietf-pcn-cl-edge-behaviour]
Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
Taylor, "PCN Boundary Node Behaviour for the Controlled Taylor, "PCN Boundary Node Behaviour for the Controlled
Load (CL) Mode of Operation", Load (CL) Mode of Operation",
draft-ietf-pcn-cl-edge-behaviour-06 (work in progress), draft-ietf-pcn-cl-edge-behaviour-08 (work in progress),
June 2010. December 2010.
[I-D.ietf-pcn-encoding-comparison] [I-D.ietf-pcn-encoding-comparison]
Chan, K., Karagiannis, G., Moncaster, T., Menth, M., Chan, K., Karagiannis, G., Moncaster, T., Menth, M.,
Eardley, P., and B. Briscoe, "Pre-Congestion Notification Eardley, P., and B. Briscoe, "Pre-Congestion Notification
Encoding Comparison", Encoding Comparison",
draft-ietf-pcn-encoding-comparison-02 (work in progress), draft-ietf-pcn-encoding-comparison-03 (work in progress),
March 2010. October 2010.
[I-D.ietf-pcn-sm-edge-behaviour] [I-D.ietf-pcn-sm-edge-behaviour]
Charny, A., Karagiannis, G., Menth, M., and T. Taylor, Charny, A., Karagiannis, G., Menth, M., and T. Taylor,
"PCN Boundary Node Behaviour for the Single Marking (SM) "PCN Boundary Node Behaviour for the Single Marking (SM)
Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-03 Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-05
(work in progress), June 2010. (work in progress), December 2010.
[I-D.ietf-tsvwg-ecn-tunnel]
Briscoe, B., "Tunnelling of Explicit Congestion
Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in
progress), March 2010.
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://bobbriscoe.net/ URI: http://bobbriscoe.net/
Toby Moncaster Toby Moncaster
Independent Moncaster Internet Consulting
Dukes
Layer Marney
Colchester CO5 9UZ
UK
Phone: +44 7764 185416
Email: toby@moncaster.com Email: toby@moncaster.com
URI: http://www.moncaster.com/
Michael Menth Michael Menth
University of Wuerzburg University of Tuebingen
room B206, Institute of Computer Science Sand 13
Am Hubland 72076 Tuebingen
Wuerzburg 97074
Germany Germany
Phone: +49 931 31 86644 Phone: +49 7071 2970505
Email: menth@informatik.uni-wuerzburg.de Email: menth@informatik.uni-tuebingen.de
 End of changes. 40 change blocks. 
122 lines changed or deleted 136 lines changed or added

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