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