draft-ietf-pcn-3-in-1-encoding-05.txt | draft-ietf-pcn-3-in-1-encoding-06.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: Standards Track Moncaster Internet Consulting | Obsoletes: 5696 (if approved) Moncaster Internet Consulting | |||
Expires: November 22, 2011 M. Menth | Intended status: Standards Track M. Menth | |||
University of Tuebingen | Expires: January 11, 2012 University of Tuebingen | |||
May 21, 2011 | July 10, 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-05 | draft-ietf-pcn-3-in-1-encoding-06 | |||
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 | The overall rate of the PCN-traffic is metered on every link in the | |||
is metered, and PCN-packets are appropriately marked when certain | PCN domain, and PCN-packets are appropriately marked when certain | |||
configured rates are exceeded. Egress nodes provide decision points | configured rates are exceeded. Egress nodes pass information about | |||
with information about the PCN-marks of PCN-packets which allows them | these PCN-marks to decision points which then decide whether to admit | |||
to take decisions about whether to admit or block a new flow request, | or block new flow requests or to terminate some already-admitted | |||
and to terminate some already admitted flows during serious pre- | flows during serious pre-congestion. | |||
congestion. | ||||
This document specifies how PCN-marks are to be encoded into the IP | This document specifies how PCN-marks are to be encoded into the IP | |||
header by re-using the Explicit Congestion Notification (ECN) | header by re-using the Explicit Congestion Notification (ECN) | |||
codepoints within a PCN-domain. This encoding builds on the baseline | codepoints within a PCN-domain. This encoding provides for up to | |||
encoding of RFC5696 and provides for three different PCN marking | three different PCN marking states using a single DSCP: not-marked | |||
states using a single DSCP: not-marked (NM), threshold-marked (ThM) | (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, | |||
and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN | it is called the 3-in-1 PCN encoding. This document obsoletes | |||
encoding. | RFC5696. | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 November 22, 2011. | This Internet-Draft will expire on January 11, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 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 | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Changes in This Version (to be removed by RFC Editor) . . 4 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | |||
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Changes in This Version (to be removed by RFC Editor) . . 5 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 7 | |||
3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5 | 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 7 | |||
3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6 | 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 8 | |||
3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7 | 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 9 | |||
4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7 | 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 9 | |||
5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN | 4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 9 | |||
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 10 | |||
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 | 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN | |||
6.1. Backward Compatibility with Pre-existing PCN | Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
Implementations . . . . . . . . . . . . . . . . . . . . . 9 | 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 10 | |||
6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9 | 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 11 | |||
6.2.1. Use of Both Excess-Traffic-Marking and | 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11 | |||
Threshold-Marking . . . . . . . . . . . . . . . . . . 10 | 5.2.2. Behaviour of PCN-interior Nodes Using Two | |||
6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 10 | PCN-markings . . . . . . . . . . . . . . . . . . . . . 11 | |||
6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10 | 5.2.3. Behaviour of PCN-interior Nodes Using One | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | PCN-marking . . . . . . . . . . . . . . . . . . . . . 11 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 5.3. Behaviour of PCN-egress Nodes . . . . . . . . . . . . . . 12 | |||
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13 | |||
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11 | 6.2. Backward Compatibility with the Baseline Encoding . . . . 13 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 12 | 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
Appendix A. Co-existence of ECN and PCN (informative) . . . . . . 13 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 | 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | ||||
12.2. Informative References . . . . . . . . . . . . . . . . . . 15 | ||||
Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 16 | ||||
Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 18 | ||||
Appendix C. Example Mapping between Encoding of PCN-Marks in | ||||
IP and in MPLS Shim Headers . . . . . . . . . . . . . 20 | ||||
Appendix D. Rationale for different behaviours for single | ||||
marking schemes . . . . . . . . . . . . . . . . . . . 21 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
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 terminate some | block a new flow request, and flow termination to terminate some | |||
existing flows during serious pre-congestion. To achieve this, the | existing flows during serious pre-congestion. To achieve this, the | |||
overall rate of PCN-traffic is metered on every link in the domain, | overall rate of PCN-traffic is metered on every link in the domain, | |||
and PCN-packets are appropriately marked when certain configured | and PCN-packets are appropriately marked when certain configured | |||
rates are exceeded. These configured rates are below the rate of the | rates are exceeded. These configured rates are below the rate of the | |||
link thus providing notification to boundary nodes about overloads | link thus providing notification to boundary nodes about overloads | |||
before any real congestion occurs (hence "pre-congestion | before any real congestion occurs (hence "pre-congestion | |||
notification"). | notification"). | |||
[RFC5670] provides for two metering and marking functions that are | [RFC5670] provides for two metering and marking functions that are | |||
configured with reference rates. Threshold-marking marks all PCN | generally configured with different reference rates. Threshold- | |||
packets once their traffic rate on a link exceeds the configured | marking marks all PCN packets once their traffic rate on a link | |||
reference rate (PCN-threshold-rate). Excess-traffic-marking marks | exceeds the configured reference rate (PCN-threshold-rate). Excess- | |||
only those PCN packets that exceed the configured reference rate | traffic-marking marks only those PCN packets that exceed the | |||
(PCN-excess-rate). The PCN-excess-rate is typically larger than the | configured reference rate (PCN-excess-rate). The PCN-excess-rate is | |||
PCN-threshold-rate [RFC5559]. Egress nodes monitor the PCN-marks of | typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes | |||
received PCN-packets and provide information about the PCN-marks to | monitor the PCN-marks of received PCN-packets and pass information | |||
decision points which take decisions about flow admission and | about these PCN-marks to decision points which then decide whether to | |||
termination on this basis [I-D.ietf-pcn-cl-edge-behaviour], | admit new flows or terminate existing flows | |||
[I-D.ietf-pcn-sm-edge-behaviour]. | [I-D.ietf-pcn-cl-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] described how two PCN | |||
marking states (Not-marked and PCN-Marked) can be encoded using a | marking states (Not-marked and PCN-Marked) could be encoded into the | |||
single Diffserv codepoint. It also provides an experimental | IP header using a single Diffserv codepoint. It also provided an | |||
codepoint (EXP), along with guidelines for use of that codepoint. To | experimental codepoint (EXP), along with guidelines for the use of | |||
support the application of two different marking algorithms in a PCN- | that codepoint. Two PCN marking states are sufficient for the Single | |||
domain, for example as required in [I-D.ietf-pcn-cl-edge-behaviour], | Marking edge behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However, | |||
three PCN marking states are needed. This document describes an | PCN-domains utilising the controlled load edge behaviour | |||
extension to the baseline encoding that uses the EXP codepoint to | [I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states. | |||
provide a third PCN marking state in the IP header, still using a | This document extends the baseline encoding by redefining the EXP | |||
single Diffserv codepoint. This encoding scheme is called "3-in-1 | codepoint to provide a third PCN marking state in the IP header, | |||
PCN encoding". | still using a single Diffserv codepoint. This encoding scheme is | |||
therefore called the "3-in-1 PCN encoding". It obsoletes the | ||||
baseline encoding [RFC5696], which provides only a sub-set of the | ||||
same capabilities. | ||||
This document only concerns the PCN wire protocol encoding for all IP | The full version of this encoding requires any tunnel endpoint within | |||
the PCN-domain to support the normal tunnelling rules defined in | ||||
[RFC6040]. There is one limited exception to this constraint where | ||||
the PCN-domain only uses the excess-traffic-marking behaviour and | ||||
where the threshold-marking behaviour is deactivated. This is | ||||
discussed in Section 5.2.3.1. | ||||
This document only concerns the PCN wire protocol encoding for 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 will define the PCN wire | |||
for other header types. For example, the MPLS encoding is defined in | protocol for other header types. Appendix C discusses a possible | |||
[RFC5129] and Appendix A of that document provides an informative | mapping between IP and MPLS. | |||
example for a mapping between the encodings in IP and in MPLS. | ||||
1.1. Changes in This Version (to be removed by RFC Editor) | 1.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
document are to be interpreted as described in [RFC2119]. | ||||
1.2. Changes in This Version (to be removed by RFC Editor) | ||||
From draft-ietf-pcn-3-in-1-encoding-05 to -06: | ||||
* Draft re-written to obsolete baseline encoding [RFC5696]. | ||||
* New section defining utilising this encoding for single | ||||
marking. Added an appendix explaining an apparent | ||||
inconsistency relating to single marking. | ||||
* Moved (and updated) informative appendixes from [RFC5696] to | ||||
this document. Original Appendix C was omitted as it is now | ||||
redundant. | ||||
* Significant re-structuring of document. | ||||
From draft-ietf-pcn-3-in-1-encoding-04 to -05: | From draft-ietf-pcn-3-in-1-encoding-04 to -05: | |||
* Draft moved to standards track as per working group | * Draft moved to standards track as per working group | |||
discussions. | discussions. | |||
* Added Appendix A discussing ECN handling in the PCN-domain. | * Added Appendix B discussing ECN handling in the PCN-domain. | |||
* Clarified that this document modifies [RFC5696]. | * Clarified that this document modifies [RFC5696]. | |||
* ....... | ||||
From draft-ietf-pcn-3-in-1-encoding-03 to -04: | From draft-ietf-pcn-3-in-1-encoding-03 to -04: | |||
* Updated document to reflect RFC6040. | * Updated document to reflect RFC6040. | |||
* Re-wrote introduction. | * Re-wrote introduction. | |||
* Re-wrote section on applicability. | * Re-wrote section on applicability. | |||
* Re-wrote section on choosing encoding scheme. | * Re-wrote section on choosing encoding scheme. | |||
skipping to change at page 5, line 26 | skipping to change at page 7, line 5 | |||
* Introduction altered to include new template description of | * Introduction altered to include new template description of | |||
PCN. | PCN. | |||
* References updated. | * References updated. | |||
* Terminology brought into line with [RFC5670]. | * Terminology brought into line with [RFC5670]. | |||
* Minor corrections. | * Minor corrections. | |||
2. Requirements Language | 2. Definitions and Abbreviations | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
document are to be interpreted as described in [RFC2119]. | ||||
2.1. Terminology | 2.1. Terminology | |||
General PCN-related terminology is defined in the PCN architecture | The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node, | |||
[RFC5559], and terminology specific to packet encoding is defined in | PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and PCN- | |||
the PCN baseline encoding [RFC5696]. Additional terminology is | marking are used as defined in [RFC5559]. The following additional | |||
defined below. | terms are defined in this document: | |||
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 | PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating | |||
packets for which the ECN field is used to carry PCN-markings | ||||
rather than [RFC3168] markings (see Appendix A). | ||||
3.1. PCN Requirements | Threshold-marked codepoint: a codepoint that indicates packets that | |||
have been marked at a PCN-interior-node as a result of an | ||||
indication from the threshold-metering function [RFC5670]. | ||||
Abbreviated to ThM. | ||||
Excess-traffic-marked codepoint: a codepoint that indicates packets | ||||
that have been marked at a PCN-interior-node as a result of an | ||||
indication from the excess-traffic-metering function [RFC5670]. | ||||
Abbreviated to ETM. | ||||
Not-marked codepoint: a codepoint that indicates PCN-packets but | ||||
that are not PCN-marked. Abbreviated to NM. | ||||
not-PCN codepoint: a codepoint that indicates packets that are not | ||||
PCN-packets. | ||||
2.2. List of Abbreviations | ||||
The following abbreviations are used in this document: | ||||
o AF = Assured Forwarding [RFC2597] | ||||
o CE = Congestion Experienced [RFC3168] | ||||
o CS = Class Selector [RFC2474] | ||||
o DSCP = Diffserv codepoint | ||||
o ECN = Explicit Congestion Notification [RFC3168] | ||||
o ECT = ECN Capable Transport [RFC3168] | ||||
o EF = Expedited Forwarding [RFC3246] | ||||
o ETM = Excess-traffic-marked | ||||
o EXP = Experimental | ||||
o IP = Internet protocol | ||||
o NM = Not-marked | ||||
o PCN = Pre-Congestion Notification | ||||
o ThM = Threshold-marked | ||||
3. Definition of 3-in-1 PCN Encoding | ||||
The 3-in-1 PCN encoding scheme allows for two or three PCN-marking | ||||
states to be encoded within the IP header. The full encoding is | ||||
shown in Figure 1. | ||||
+--------+----------------------------------------------------+ | ||||
| | Codepoint in ECN field of IP header | | ||||
| DSCP | <RFC3168 codepoint name> | | ||||
| +--------------+-------------+-------------+---------+ | ||||
| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> | | ||||
+--------+--------------+-------------+-------------+---------+ | ||||
| DSCP n | Not-PCN | NM | ThM | ETM | | ||||
+--------+--------------+-------------+-------------+---------+ | ||||
Figure 1: 3-in-1 PCN Encoding | ||||
As mentioned above, the 3-in-1 PCN encoding is an extension of the | ||||
baseline encoding [RFC5696]. Like the baseline encoding it uses a | ||||
combination of a PCN-compatible DSCP (DSCP n in Figure 1) and the ECN | ||||
field for the encoding of PCN-marks. Appendix A discusses the choice | ||||
of suitable DSCPs. The PCN-marks have the following meaning. | ||||
Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not | ||||
subject to PCN metering and marking. | ||||
NM: Not-marked. Indicates a PCN-packet that has not yet been marked | ||||
by any PCN marker. | ||||
ThM: Threshold-marked. Indicates a PCN-packet that has been marked | ||||
by a threshold-marker [RFC5670]. | ||||
ETM: Excess-traffic-marked. Indicates a PCN-packet that has been | ||||
marked by an excess-traffic-marker [RFC5670]. | ||||
4. Requirements for and Applicability of 3-in-1 PCN Encoding | ||||
4.1. PCN Requirements | ||||
In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes | In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes | |||
control packets entering a PCN-domain. Packets belonging to PCN- | control packets entering a PCN-domain. Packets belonging to PCN- | |||
controlled flows are subject to PCN-metering and -marking, and PCN- | controlled flows are subject to PCN-metering and -marking, and PCN- | |||
ingress-nodes mark them as Not-marked (PCN-colouring). Any node in | ingress-nodes mark them as Not-marked (PCN-colouring). Any node in | |||
the PCN-domain may perform PCN-metering and -marking and mark PCN- | the PCN-domain may perform PCN-metering and -marking and mark PCN- | |||
packets if needed. There are two different metering and marking | packets if needed. There are two different metering and marking | |||
schemes: threshold-marking and excess-traffic-marking [RFC5670]. | behaviours: threshold-marking and excess-traffic-marking [RFC5670]. | |||
Some edge behaviors require only a single marking scheme | Some edge behaviors require only a single marking behaviour | |||
[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]. Threshold-marking and | marked by the excess-traffic-marker [RFC5670]. Threshold-marking and | |||
excess-traffic-marking are configured to start marking packets at | excess-traffic-marking are configured to start marking packets at | |||
different load conditions, so one marking scheme indicates more | different load conditions, so one marking behaviour indicates more | |||
severe pre-congestion than the other. Therefore, a fourth PCN | severe pre-congestion than the other. Therefore, a fourth PCN | |||
marking state indicating that a packet is marked by both markers is | marking state indicating that a packet is marked by both markers is | |||
not needed. However a fourth codepoint is required to indicate | not needed. However a fourth codepoint is required to indicate | |||
packets that are not PCN-capable (the not-PCN codepoint). | packets that do not use PCN (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 behaviours | |||
[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 | 4.2. Requirements Imposed by Tunnelling | |||
The baseline encoding scheme [RFC5696] was defined so that it could | [RFC6040] defines rules for the encapsulation and decapsulation of | |||
be extended to accommodate an additional marking state. It provides | ECN markings within IP-in-IP tunnels. The publication of RFC6040 | |||
rules to embed the encoding of two PCN states in the IP header. | removed the tunnelling constraints that existed when the baseline | |||
Figure 1 shows the structure of the former type-of-service field. It | encoding [RFC5696] was written (see section 3.3.2 of | |||
contains the 6-bit Differentiated Services (DS) field that holds the | [I-D.ietf-pcn-encoding-comparison]). | |||
DS codepoint (DSCP) [RFC2474] and the 2-bit ECN field [RFC3168]. | ||||
0 1 2 3 4 5 6 7 | Nonetheless, there is still a problem if there are any legacy (pre- | |||
+-----+-----+-----+-----+-----+-----+-----+-----+ | RFC6040) decapsulating tunnel endpoints within a PCN domain. If a | |||
| DS FIELD | ECN FIELD | | PCN node Threshold-marks the outer header of a tunnelled packet with | |||
+-----+-----+-----+-----+-----+-----+-----+-----+ | a Not-marked codepoint on the inner header, the legacy decapsulator | |||
will revert the Threshold-marking to Not-marked. The rules on | ||||
applicability in Section 4.3 below are designed to avoid this | ||||
problem. | ||||
Figure 1: Structure of the former type-of-service field in IP | 4.3. Applicability of 3-in-1 PCN Encoding | |||
Baseline encoding defines that the DSCP must be set to a PCN- | The 3-in-1 encoding is applicable in situations where two marking | |||
compatible DSCP n and the ECN-field [RFC3168] indicates the specific | behaviours are being used in the PCN-domain. The 3-in-1 encoding can | |||
PCN-mark. Baseline encoding offers four possible encoding states | also be used with only one marking behaviour, in which case one of | |||
within a single DSCP with the following restrictions. | the codepoints MUST NOT be used throughout the PCN-domain (see | |||
Section 5.2.3). | ||||
o Codepoint `00' (not-ECT) is used to indicate non-PCN traffic as | For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP | |||
"not-PCN". This allows both PCN and non-PCN traffic to use the | and IPsec) within the PCN-domain MUST comply with the ECN | |||
same DSCP. | encapsulation and decapsulation rules set out in [RFC6040] (see | |||
Section 4.2). There is one exception to this rule outlined next. | ||||
o Codepoint `10' (ECT(0)) is used to indicate Not-marked PCN | It may not be possible to upgrade every pre-RFC6040 tunnel endpoint | |||
traffic. | within a PCN-domain. In such cirsumstances a limited version of the | |||
3-in-1 encoding can still be used but only under the following | ||||
stringent condition. If any pre-RFC6040 tunnel endpoint exists | ||||
within a PCN-domain then every PCN-node in the PCN-domain MUST be | ||||
configured so that it never sets the ThM codepoint. The behaviour of | ||||
PCN-interior nodes in this case is defined in Section 5.2.3.1. In | ||||
all other situations where legacy tunnel endpoints might be present | ||||
within the PCN domain, the 3-in-1 encoding is not applicable. | ||||
o Codepoint `11' (CE) is used to indicate the most severe PCN-mark. | 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding | |||
o Codepoint `01' (ECT(1)) is available for experimental use and may | As mentioned in Section 4.3 above, all PCN-nodes MUST comply with | |||
be re-used by other PCN encodings such as the presently defined | [RFC6040]. | |||
3-in-1 PCN encoding (subject to the rules defined in [RFC5696]). | ||||
[RFC6040] defines rules for the encapsulation and decapsulation of | 5.1. PCN-ingress Node Behaviour | |||
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 | ||||
[RFC6040]. In particular, the relative severity of each marking is | ||||
the same: CE (PM) is more severe than ECT(1) (EXP) is more severe | ||||
than ECT(0) (NM). This is discussed in more detail in both the | ||||
baseline encoding document [RFC5696] and in | ||||
[I-D.ietf-pcn-encoding-comparison]. | ||||
3.3. Applicability of 3-in-1 PCN Encoding | PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint. | |||
To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are | ||||
already defined for use with admission-controlled traffic. | ||||
Appendix A gives guidance to implementors on suitable DSCPs. | ||||
Guidelines for mixing traffic types within a PCN-domain are given in | ||||
[RFC5670]. | ||||
The 3-in-1 encoding is applicable in situations where two marking | If a packet arrives at the PCN-ingress-node that shares a PCN- | |||
schemes are being used in the PCN-domain. In some circumstances it | compatible DSCP and is not a PCN-packet, the PCN-ingress MUST mark it | |||
can also be used in PCN-domains with only a single marking scheme in | as not-PCN. | |||
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 | If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress MUST | |||
change the PCN codepoint to Not-marked. | ||||
The 3-in-1 PCN encoding scheme is an extension of the baseline | If a PCN-packet arrives at the PCN-ingress-node with its ECN field | |||
encoding scheme defined in [RFC5696]. The PCN requirements and the | already set to a value other than not-ECT, then appropriate action | |||
extension rules for baseline encoding presented in the previous | MUST be taken to meet the requirements of [RFC4774]. The simplest | |||
section determine how PCN encoding states are carried in the IP | appropriate action is to just drop such packets. However, this is a | |||
headers. This is shown in Figure 2. | drastic action that an operator may feel is undesirable. Appendix B | |||
provides more information and summarises other alternative actions | ||||
that might be taken. | ||||
+--------+----------------------------------------------------+ | 5.2. PCN-interior Node Behaviour | |||
| | Codepoint in ECN field of IP header | | ||||
| DSCP | <RFC3168 codepoint name> | | ||||
| +--------------+-------------+-------------+---------+ | ||||
| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> | | ||||
+--------+--------------+-------------+-------------+---------+ | ||||
| DSCP n | Not-PCN | NM | ThM | ETM | | ||||
+--------+--------------+-------------+-------------+---------+ | ||||
Figure 2: 3-in-1 PCN Encoding | ||||
Like baseline encoding, 3-in-1 PCN encoding also uses a PCN | 5.2.1. Behaviour Common to all PCN-interior Nodes | |||
compatible DSCP n and the ECN field for the encoding of PCN-marks. | ||||
The PCN-marks have the following meaning. | ||||
Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not | Interior nodes MUST NOT change not-PCN to any other codepoint. | |||
subject to PCN metering and marking. | ||||
NM: Not-marked. Indicates a PCN-packet that has not yet been marked | Interior nodes MUST NOT change NM to not-PCN. | |||
by any PCN marker. | ||||
ThM: Threshold-marked. Indicates a PCN-packet that has been marked | Interior nodes MUST NOT change ThM to NM or not-PCN. | |||
by a threshold-marker [RFC5670]. | ||||
ETM: Excess-traffic-marked. Indicates a PCN-packet that has been | Interior nodes MUST NOT change ETM to any other codepoint. | |||
marked by an excess-traffic-marker [RFC5670]. | ||||
5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding | 5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings | |||
To be compliant with the 3-in-1 PCN Encoding, an PCN interior node | If the threshold-meter function indicates a need to mark the packet, | |||
behaves as follows: | the PCN-interior node MUST change NM to ThM. | |||
o It MUST change NM to ThM if the threshold-meter function indicates | If the excess-traffic-meter function indicates a need to mark the | |||
a need to mark the packet; | packet: | |||
o It MUST change NM or ThM to ETM if the excess-traffic-meter | o the PCN-interior node MUST change NM to ETM; | |||
function indicates a need to mark the packet; | ||||
o It MUST NOT change not-PCN to NM, ThM, or ETM; | o the PCN-interior node MUST change ThM to ETM. | |||
o It MUST NOT change a NM, ThM, or ETM to not-PCN; | If both the threshold meter and the excess-traffic meter indicate the | |||
need to mark a packet, the excess traffic marking rules MUST take | ||||
priority. | ||||
o It MUST NOT change ThM to NM; | 5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking | |||
o It MUST NOT change ETM to ThM or to NM; | Some PCN edge behaviours require only one PCN-marking within the PCN- | |||
domain. The Single Marking edge behaviour | ||||
[I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark | ||||
packets using the excess-traffic-meter function [RFC5670]. It is | ||||
possible that future schemes may require only the threshold-meter | ||||
function. Observant readers may spot an apparent inconsistency | ||||
between the two following cases. Appendix D explains the rationale | ||||
behind this inconsistency. | ||||
In other words, a PCN interior node MUST NOT mark PCN-packets into | 5.2.3.1. Marking using only the Excess-traffic-meter Function | |||
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. | ||||
6. Backward Compatibility | The threshold-traffic-meter function SHOULD be disabled and MUST NOT | |||
trigger any packet marking. | ||||
Discussion of backward compatibility between PCN encoding schemes and | The PCN-interior node SHOULD raise a management alarm if it receives | |||
previous uses of the ECN field is given in Section 6 of [RFC5696]. | a ThM packet, but the frequency of such alarms SHOULD be limited. | |||
6.1. Backward Compatibility with Pre-existing PCN Implementations | If the excess-traffic-meter function indicates a need to mark the | |||
packet: | ||||
This encoding complies with the rules for extending the baseline PCN | o the PCN-interior node MUST change NM to ETM; | |||
encoding schemes in Section 5 of [RFC5696]. | ||||
The term "compatibility" is meant in the following sense. It is | o the PCN-interior node MUST change ThM to ETM. It SHOULD also | |||
possible to operate nodes with baseline encoding [RFC5696] and 3-in-1 | raise an alarm as above. | |||
encoding in the same PCN domain. The nodes with baseline encoding | ||||
MUST perform excess-traffic-marking because the 11 codepoint of | ||||
3-in-1 encoding also means excess-traffic-marked. PCN-boundary-nodes | ||||
of such domains are required to interpret the full 3-in-1 encoding | ||||
and not just baseline encoding, otherwise they cannot interpret the | ||||
01 codepoint. | ||||
Using nodes that perform only excess-traffic-marking may make sense | 5.2.3.2. Marking using only the Threshold-meter Function | |||
in networks using the CL edge behavior | ||||
[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 | ||||
terminated. This seems reasonable for locations that are not | ||||
expected to see any pre-congestion, but excess-traffic-marking gives | ||||
them a means to terminate traffic if unexpected overload occurs. | ||||
6.2. Recommendations for the Use of PCN Encoding Schemes | The excess-traffic-meter function SHOULD be disabled and MUST NOT | |||
trigger any packet marking. | ||||
NOTE: This sub-section is informative not normative. | The PCN-interior node SHOULD raise a management alarm if it receives | |||
an ETM packet, but the frequency of such alarms SHOULD be limited. | ||||
When deciding which PCN encoding is suitable an operator needs to | If the threshold-meter function indicates a need to mark the packet: | |||
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. | ||||
+------------------------+--------------------------------+ | o the PCN-interior node MUST change NM to ThM; | |||
| Marking schemes in use | 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 | o the PCN-interior node MUST NOT change ETM to any other codepoint. | |||
It SHOULD raise an alarm as above. | ||||
6.2.1. Use of Both Excess-Traffic-Marking and Threshold-Marking | 5.3. Behaviour of PCN-egress Nodes | |||
If both excess-traffic-marking and threshold-marking are enabled in a | A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all | |||
PCN-domain, 3-in-1 encoding should be used as described in this | packets it forwards out of the PCN-domain. | |||
document. | ||||
6.2.2. Unique Use of Excess-Traffic-Marking | The only exception to this is if the PCN-egress-node is certain that | |||
revealing other codepoints outside the PCN-domain won't contravene | ||||
the guidance given in [RFC4774]. For instance, if the PCN-ingress- | ||||
node has explicitly informed the PCN-egress-node that this flow is | ||||
ECN-capable, then it might be safe to expose other codepoints. | ||||
Appendix B gives details of how such schemes might work, but such | ||||
schemes are currently experimental. | ||||
If only excess-traffic-marking is enabled in a PCN-domain, baseline | If the PCN-domain is configured to use only excess-traffic marking, | |||
encoding or 3-in-1 encoding may be used. They lead to the same | the PCN-egress node MUST treat ThM as ETM and if only threshold- | |||
encoding because PCN-boundary nodes will interpret baseline "PCN- | marking is used it should treat ETM as ThM. However it SHOULD raise | |||
marked (PM)" as "excess-traffic-marked (ETM)". | a management alarm in either instance since this means there is some | |||
misconfiguration in the PCN-domain. | ||||
6.2.3. Unique Use of Threshold-Marking | 6. Backward Compatibility | |||
No scheme is currently proposed that solely uses threshold-marking. | 6.1. Backward Compatibility with ECN | |||
If such a scheme is proposed, the choice of encoding scheme will | ||||
depend on whether nodes are compliant with [RFC6040] or not. Where | BCP 124 [RFC4774] gives guidelines for specifying alternative | |||
it is certain that all nodes in the PCN-domain are compliant then | semantics for the ECN field. It sets out a number of factors to be | |||
either 3-in-1 encoding or baseline encoding are suitable. If legacy | taken into consideration. It also suggests various techniques to | |||
tunnel decapsulators exist within the PCN-domain then baseline | allow the co-existence of default ECN and alternative ECN semantics. | |||
encoding SHOULD be used. | The encoding specified in this document uses one of those techniques; | |||
it defines PCN-compatible Diffserv codepoints as no longer supporting | ||||
the default ECN semantics. As such, this document is compatible with | ||||
BCP 124. | ||||
On its own, the 3-in-1 encoding cannot support both ECN marking end- | ||||
to-end (e2e) and PCN-marking within a PCN-domain. Appendix B | ||||
discusses possible ways to do this, e.g. by carrying e2e ECN across a | ||||
PCN-domain within the inner header of an IP-in-IP tunnel. Although | ||||
Appendix B recommends various approaches over others, it is merely | ||||
informative and all such schemes are beyond the normative scope of | ||||
this document. | ||||
In any PCN deployment, traffic can only enter the PCN-domain through | ||||
PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress- | ||||
nodes ensure that any packets entering the PCN-domain have the ECN | ||||
field in their outermost IP header set to the appropriate PCN | ||||
codepoint. PCN-egress-nodes then guarantee that the ECN field of any | ||||
packet leaving the PCN-domain has appropriate ECN semantics. This | ||||
prevents unintended leakage of ECN marks into or out of the PCN- | ||||
domain, and thus reduces backward-compatibility issues. | ||||
6.2. Backward Compatibility with the Baseline Encoding | ||||
A PCN node implemented to use the obsoleted baseline encoding could | ||||
conceivably have been configured so that the Threshold-meter function | ||||
marked what is now defined as the ETM codepoint in the 3-in-1 | ||||
encoding. However, thre is no known deployment of such an | ||||
implementation and no reason to believe that such an implementation | ||||
would ever have been built. Therefore, it seems safe to ignore this | ||||
issue. | ||||
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 | |||
The security concerns relating to this extended PCN encoding are the | PCN-marking only carries a meaning within the confines of a PCN- | |||
same as those in [RFC5696]. In summary, PCN-boundary nodes are | domain. This encoding document is intended to stand independently of | |||
responsible for ensuring inappropriate PCN markings do not leak into | the architecture used to determine how specific packets are | |||
or out of a PCN domain, and the current phase of the PCN architecture | authorised to be PCN-marked, which will be described in separate | |||
assumes that all the nodes of a PCN-domain are entirely under the | documents on PCN-boundary-node behaviour. | |||
control of a single operator, or a set of operators who trust each | ||||
other. | ||||
Given the only difference between the baseline encoding and the | This document assumes the PCN-domain to be entirely under the control | |||
present 3-in-1 encoding is the use of the 01 codepoint, no new | of a single operator, or a set of operators who trust each other. | |||
security issues are raised, as this codepoint was already available | However, future extensions to PCN might include inter-domain versions | |||
for experimental use in the baseline encoding. | where trust cannot be assumed between domains. If such schemes are | |||
proposed, they must ensure that they can operate securely despite the | ||||
lack of trust. However, such considerations are beyond the scope of | ||||
this document. | ||||
One potential security concern is the injection of spurious PCN-marks | ||||
into the PCN-domain. However, these can only enter the domain if a | ||||
PCN-ingress-node is misconfigured. The precise impact of any such | ||||
misconfiguration will depend on which of the proposed PCN-boundary- | ||||
node behaviours is used, but in general spurious marks will lead to | ||||
admitting fewer flows into the domain or potentially terminating too | ||||
many flows. In either case, good management should be able to | ||||
quickly spot the problem since the overall utilisation of the domain | ||||
will rapidly fall. | ||||
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 | In general, the use of this PCN encoding scheme presupposes that any | |||
the PCN region have been updated to comply with [RFC6040]. | tunnel endpoints within the PCN-domain comply with [RFC6040]. | |||
10. Acknowledgements | 10. Acknowledgements | |||
Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan and Georgios | Many thanks to Phil Eardley for providing extensive feedback, | |||
Karaginannis for reviewing this document. | critcism and advice. Thanks also to Teco Boot, Kwok Ho Chan, | |||
Ruediger Geib, Georgios Karaginannis and everyone else who has | ||||
commented on the 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 | |||
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. | |||
12. References | 12. References | |||
skipping to change at page 11, line 42 | skipping to change at page 15, line 28 | |||
[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 | |||
of Explicit Congestion Notification (ECN) to IP", | of Explicit Congestion Notification (ECN) to IP", | |||
RFC 3168, September 2001. | RFC 3168, September 2001. | |||
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit | ||||
Congestion Notification (ECN) Signaling with Nonces", | ||||
RFC 3540, June 2003. | ||||
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the | ||||
Internet Protocol", RFC 4301, December 2005. | ||||
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration | ||||
Guidelines for DiffServ Service Classes", RFC 4594, | ||||
August 2006. | ||||
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion | ||||
Marking in MPLS", RFC 5129, January 2008. | ||||
[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 | ||||
Encoding and Transport of Pre-Congestion Information", | ||||
RFC 5696, November 2009. | ||||
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated | ||||
Services Code Point (DSCP) for Capacity-Admitted Traffic", | ||||
RFC 5865, May 2010. | ||||
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion | [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion | |||
Notification", RFC 6040, November 2010. | 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-08 (work in progress), | draft-ietf-pcn-cl-edge-behaviour-09 (work in progress), | |||
December 2010. | June 2011. | |||
[I-D.ietf-pcn-encoding-comparison] | [I-D.ietf-pcn-encoding-comparison] | |||
Karagiannis, G., Chan, K., Moncaster, T., Menth, M., | Karagiannis, G., Chan, K., Moncaster, T., Menth, M., | |||
Eardley, P., and B. Briscoe, "Overview of Pre-Congestion | Eardley, P., and B. Briscoe, "Overview of Pre-Congestion | |||
Notification Encoding", | Notification Encoding", | |||
draft-ietf-pcn-encoding-comparison-05 (work in progress), | draft-ietf-pcn-encoding-comparison-06 (work in progress), | |||
April 2011. | June 2011. | |||
[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-05 | Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-06 | |||
(work in progress), December 2010. | (work in progress), June 2011. | |||
Appendix A. Co-existence of ECN and PCN (informative) | [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, | |||
"Assured Forwarding PHB Group", RFC 2597, June 1999. | ||||
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, | ||||
J., Courtney, W., Davari, S., Firoiu, V., and D. | ||||
Stiliadis, "An Expedited Forwarding PHB (Per-Hop | ||||
Behavior)", RFC 3246, March 2002. | ||||
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit | ||||
Congestion Notification (ECN) Signaling with Nonces", | ||||
RFC 3540, June 2003. | ||||
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration | ||||
Guidelines for DiffServ Service Classes", RFC 4594, | ||||
August 2006. | ||||
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the | ||||
Explicit Congestion Notification (ECN) Field", BCP 124, | ||||
RFC 4774, November 2006. | ||||
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of | ||||
DiffServ Service Classes", RFC 5127, February 2008. | ||||
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion | ||||
Marking in MPLS", RFC 5129, January 2008. | ||||
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching | ||||
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic | ||||
Class" Field", RFC 5462, February 2009. | ||||
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline | ||||
Encoding and Transport of Pre-Congestion Information", | ||||
RFC 5696, November 2009. | ||||
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated | ||||
Services Code Point (DSCP) for Capacity-Admitted Traffic", | ||||
RFC 5865, May 2010. | ||||
Appendix A. Choice of Suitable DSCPs | ||||
This appendix is informative, not normative. | ||||
The PCN working group chose not to define a single DSCP for use with | ||||
PCN for several reasons. Firstly, the PCN mechanism is applicable to | ||||
a variety of different traffic classes. Secondly, Standards Track | ||||
DSCPs are in increasingly short supply. Thirdly, PCN is not a | ||||
scheduling behaviour -- rather, it should be seen as being a marking | ||||
behaviour similar to ECN but intended for inelastic traffic. The | ||||
choice of which DSCP is most suitable for a given PCN-domain is | ||||
dependent on the nature of the traffic entering that domain and the | ||||
link rates of all the links making up that domain. In PCN-domains | ||||
with sufficient aggregation, the appropriate DSCPs would currently be | ||||
those for the Real-Time Treatment Aggregate [RFC5127]. The PCN | ||||
working group suggests using admission control for the following | ||||
service classes (defined in [RFC4594]): | ||||
o Telephony (EF) | ||||
o Real-time interactive (CS4) | ||||
o Broadcast Video (CS3) | ||||
o Multimedia Conferencing (AF4) | ||||
CS5 is excluded from this list since PCN is not expected to be | ||||
applied to signalling traffic. PCN can also be applied to the VOICE- | ||||
ADMIT codepoint defined in [RFC5865]. | ||||
PCN-marking is intended to provide a scalable admission-control | ||||
mechanism for traffic with a high degree of statistical multiplexing. | ||||
PCN-marking would therefore be appropriate to apply to traffic in the | ||||
above classes, but only within a PCN-domain containing sufficiently | ||||
aggregated traffic. In such cases, the above service classes may | ||||
well all be subject to a single forwarding treatment (treatment | ||||
aggregate [RFC5127]). However, this does not imply all such IP | ||||
traffic would necessarily be identified by one DSCP -- each service | ||||
class might keep a distinct DSCP within the highly aggregated region | ||||
[RFC5127]. | ||||
Additional service classes may be defined for which admission control | ||||
is appropriate, whether through some future standards action or | ||||
through local use by certain operators, e.g., the Multimedia | ||||
Streaming service class (AF3). This document does not preclude the | ||||
use of PCN in more cases than those listed above. | ||||
Note: The above discussion is informative not normative, as operators | ||||
are ultimately free to decide whether to use admission control for | ||||
certain service classes and whether to use PCN as their mechanism of | ||||
choice. | ||||
Appendix B. Co-existence of ECN and PCN | ||||
This appendix is informative, not normative. | ||||
The PCN encoding described in this document re-uses the bits of the | The PCN encoding described in this document re-uses the bits of the | |||
ECN field in the IP header. Consequently, this disables ECN within | ECN field in the IP header. Consequently, this disables ECN within | |||
the PCN domain. Appendix B of [RFC5696] included advice on handling | the PCN domain. Appendix B of [RFC5696] (obsoleted) included advice | |||
ECN traffic within a PCN-domain. This appendix clarifies that | on handling ECN traffic within a PCN-domain. This appendix | |||
advice. | reiterates and clarifies that advice. | |||
For the purposes of this appendix we define two forms of traffic that | For the purposes of this appendix we define two forms of traffic that | |||
might arrive at a PCN-ingress node. These are Admission-controlled | might arrive at a PCN-ingress node. These are Admission-controlled | |||
traffic and Non-admission-controlled traffic. | traffic and Non-admission-controlled traffic. | |||
Admission-controlled traffic will be remarked to the PCN-compatible | Admission-controlled traffic will be remarked to a PCN-compatible | |||
DSCP by the PCN-ingress node. Two mechanisms can be used to identify | DSCP by the PCN-ingress node. Two mechanisms can be used to identify | |||
such traffic: | such traffic: | |||
a. flow signalling associates a filterspec with a need for admission | a. flow signalling associates a filterspec with a need for admission | |||
control (e.g. through RSVP or some equivalent message down from a | control (e.g. through RSVP or some equivalent message, e.g. from | |||
SIP server to the ingress), and the PCN-ingress remarks traffic | a SIP server to the ingress), and the PCN-ingress remarks traffic | |||
matching that filterspec to a PCN-compatible DSCP, as its chosen | matching that filterspec to a PCN-compatible DSCP, as its chosen | |||
admission control mechanism. | admission control mechanism. | |||
b. Traffic arrives with a DSCP that implies it requires admission | b. Traffic arrives with a DSCP that implies it requires admission | |||
control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, | control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, | |||
Broadcast TV when used for video on demand, and Multimedia | Broadcast TV when used for video on demand, and Multimedia | |||
Conferencing [RFC4594][RFC5865]. | Conferencing [RFC4594][RFC5865]. | |||
All other traffic can be thought of as Non-admission-controlled. | All other traffic can be thought of as Non-admission-controlled (and | |||
However such traffic may still need to share the same DSCP as the | therefore outside the scope of PCN). However such traffic may still | |||
Admission-controlled traffic. This may be due to policy (for | need to share the same DSCP as the Admission-controlled traffic. | |||
instance if it is high priority voice traffic), or may be because | This may be due to policy (for instance if it is high priority voice | |||
there is a shortage of local DSCPs. | traffic), or may be because there is a shortage of local DSCPs. | |||
ECN [RFC3168] is an end-to-end congestion notification mechanism. As | ECN [RFC3168] is an end-to-end congestion notification mechanism. As | |||
such it is possible that some traffic entering the PCN-domain may | such it is possible that some traffic entering the PCN-domain may | |||
also be ECN capable The following lists the four cases for how e2e | also be ECN capable. | |||
ECN traffic may wish to be treated while crossing a PCN domain: | ||||
Unless specified otherwise, for any of the cases in the list below, | ||||
an IP-in-IP tunnel can be used to preserve ECN markings across the | ||||
PCN domain. However the tunnelling action should be applied wholly | ||||
outside the PCN-domain as illustrated in the following figure: | ||||
, . . . . . PCN-domain . . . . . . | ||||
. ,--------. ,--------. . | ||||
. _| PCN- |___________________| PCN- |_ . | ||||
. / | ingress | | egress | \ . | ||||
.| '---------' '--------' |. | ||||
| . . . . . . . . . . . . . . .| | ||||
,--------. ,--------. | ||||
_____| Tunnel | | Tunnel |____ | ||||
| Ingress | - - ECN preserved inside tunnel - - | Egress | | ||||
'---------' '--------' | ||||
Figure 2: Separation of tunneling and PCN actions | ||||
There are four cases for how e2e ECN traffic may wish to be treated | ||||
while crossing a PCN domain: | ||||
ECN capable traffic that does not require admission control and does | ECN capable traffic that does not require admission control and does | |||
not carry a DSCP that the PCN-ingress is using for PCN-capable | not carry a DSCP that the PCN-ingress is using for PCN-capable | |||
traffic. This requires no action. | traffic. This requires no action. | |||
ECN capable traffic that does not require admission control but | ECN capable traffic that does not require admission control but | |||
carries a DSCP that the PCN-ingress is using for PCN-capable | carries a DSCP that the PCN-ingress is using for PCN-capable | |||
traffic. There are two options. | traffic. There are two options. | |||
* The ingress maps the DSCP to a local DSCP with the same | * The ingress maps the DSCP to a local DSCP with the same | |||
scheduling PHB as the original DSCP, and the egress re-maps it | scheduling PHB as the original DSCP, and the egress re-maps it | |||
to the original PCN-compatible DSCP. | to the original PCN-compatible DSCP. | |||
* The ingress tunnels the traffic, setting not-PCN in the outer | * The ingress tunnels the traffic, setting not-PCN in the outer | |||
header; note that this turns off ECN for this traffic within | header; note that this turns off ECN for this traffic within | |||
the PCN domain. | the PCN domain. | |||
skipping to change at page 14, line 25 | skipping to change at page 20, line 5 | |||
ECN-capable Admission-controlled traffic: There are two options. | ECN-capable Admission-controlled traffic: There are two options. | |||
* The PCN-ingress places this traffic in a tunnel with a PCN- | * The PCN-ingress places this traffic in a tunnel with a PCN- | |||
compatible DSCP in the outer header. The PCN-egress zeroes the | compatible DSCP in the outer header. The PCN-egress zeroes the | |||
ECN-field before decapsulation. | ECN-field before decapsulation. | |||
* The PCN-ingress drops CE-marked packets and the PCN-egress | * The PCN-ingress drops CE-marked packets and the PCN-egress | |||
zeros the ECN field of all PCN packets. | zeros the ECN field of all PCN packets. | |||
The second option is not recommended unless tunnelling is not | The second option is emphatically not recommended, unless perhaps | |||
possible for some reason.. | as a last resort if tunnelling is not possible for some | |||
insurmountable reason. | ||||
ECN-capable Admission-controlled where the e2e transport somehow | ECN-capable Admission-controlled traffic where the e2e transport | |||
indicates that it wants to see PCN marks: NOTE this is currently | somehow indicates that it wants to see PCN marks: NOTE this is | |||
experimental only. | currently tentative only. | |||
Schemes have been suggested where PCN marks may be leaked out of | Schemes have been suggested where PCN marks may be leaked out of | |||
the PCN-domain and used by the end hosts to modify realtime data | the PCN-domain and used by the end hosts to modify realtime data | |||
rates. Currently all such schemes are experimental and the | rates. Currently all such schemes require further study and the | |||
following is for guidance only. | following is for guidance only. | |||
The PCN-ingress needs to tunnel the traffic using [RFC6040]. The | The PCN-ingress needs to tunnel the traffic, taking care to comply | |||
PCN-egress should not zero the ECN field, and the tunnel egress | with [RFC6040]. In this case the PCN-egress should not zero the | |||
should use [RFC6040] normal mode (preserving any PCN-marking). | ECN field, and then the [RFC6040] tunnel egress will preserve any | |||
Note that this may turn ECT(0) into ECT(1) and so is not | PCN-marking. Note that a PCN interior node may turn ECT(0) into | |||
compatible with the experimental ECN nonce [RFC3540]. | ECT(1), which would not be compatible with the (currently | |||
experimental) ECN nonce [RFC3540]. | ||||
In the list above any form of IP-in-IP tunnel can be used unless | Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in | |||
specified otherwise. NB, We assume a logical separation of tunneling | MPLS Shim Headers | |||
and PCN actions in both PCN-ingress and PCN-egress nodes. That is, | ||||
any tunneling action happens wholly outside the PCN-domain as | ||||
illustrated in the following figure: | ||||
, . . . . . PCN-domain . . . . . . | This appendix is informative not normative. | |||
. ,--------. ,--------. . | ||||
. _| PCN- |___________________| PCN- |_ . | ||||
. / | ingress | | egress | \ . | ||||
.| '---------' '--------' |. | ||||
| . . . . . . . . . . . . . . .| | ||||
,--------. ,--------. | ||||
_____| Tunnel | | Tunnel |____ | ||||
| Ingress | - - ECN preserved inside tunnel - - | Egress | | ||||
'---------' '--------' | ||||
Figure 4: Separation of tunneling and PCN actions | The 6 bits of the DS field in the IP header provide for 64 | |||
codepoints. When encapsulating IP traffic in MPLS, it is useful to | ||||
make the DS field information accessible in the MPLS header. | ||||
However, the MPLS shim header has only a 3-bit traffic class (TC) | ||||
field [RFC5462] providing for 8 codepoints. The operator has the | ||||
freedom to define a site-local mapping of a subset of the 64 | ||||
codepoints of the DS field to the 8 codepoints in the TC field. | ||||
[RFC5129] describes how ECN markings in the IP header can also be | ||||
mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129] | ||||
gives an informative description of how to support PCN in MPLS by | ||||
extending the way MPLS supports ECN. But [RFC5129] was written while | ||||
PCN specifications were in early draft stages. The following | ||||
provides a clearer example of a mapping between PCN in IP and in MPLS | ||||
using the PCN terminology and concepts that have since been | ||||
specified. | ||||
To support PCN in a MPLS domain, codepoints for all used PCN-marks | ||||
need to be provided in the TC field. That means, when e.g. only | ||||
excess-traffic-marking is used for PCN purposes, the operator needs | ||||
to define a site-local mapping to codepoints in the MPLS TC field for | ||||
IP headers with: | ||||
o DSCP n and ECT(0) | ||||
o DSCP n and CE | ||||
If both excess-traffic-marking and threshold-marking are used, the | ||||
operator needs to define a site-local mapping to codepoints in the | ||||
MPLS TC field for IP headers with all three of the 3-in-1 codepoints: | ||||
o DSCP n and ECT(0) | ||||
o DSCP n and ECT(1) | ||||
o DSCP n and CE | ||||
In either case, if the operator wishes to support the same Diffserv | ||||
PHB but without PCN marking, it will also be necessary to define a | ||||
site-local mapping to an MPLS TC codepoint for IP headers marked | ||||
with: | ||||
o DSCP n and Not-ECT | ||||
Appendix D. Rationale for different behaviours for single marking | ||||
schemes | ||||
Readers may notice an apparent discrepancy between the two single | ||||
marking behaviours in Section 5.2.3.1 and Section 5.2.3.2. For the | ||||
excess-traffic only marking an unexpected ThM marked packet is | ||||
remarked as ETM. For the threshold only marking, an unexpected ETM | ||||
marked packet is simply ignored (apart from an optional management | ||||
alarm). | ||||
There are two reasons for having these seemingly contradictory | ||||
requirements. Firstly these behaviours conform with the expected | ||||
behaviour where both metering functions are being used for marking-- | ||||
ETM is always a more severe marking than ThM and so should never be | ||||
re-marked. Secondly the threshold-metering behaviour in [RFC5670] | ||||
uses the current marking state of the arriving packet to determine | ||||
what action to take. Consequently, in the ETM only marking it would | ||||
be potentially unsafe to allow ThM packets to propagate forward in | ||||
the network as they may adversely affect the threshold-metering | ||||
function. | ||||
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 | |||
End of changes. 90 change blocks. | ||||
317 lines changed or deleted | 601 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |