draft-ietf-pcn-3-in-1-encoding-08.txt | draft-ietf-pcn-3-in-1-encoding-09.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 | |||
Obsoletes: 5696 (if approved) Moncaster Internet Consulting | Obsoletes: 5696 (if approved) Moncaster Internet Consulting | |||
Intended status: Standards Track M. Menth | Intended status: Standards Track M. Menth | |||
Expires: February 19, 2012 University of Tuebingen | Expires: September 12, 2012 University of Tuebingen | |||
August 18, 2011 | March 11, 2012 | |||
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-08 | draft-ietf-pcn-3-in-1-encoding-09 | |||
Abstract | Abstract | |||
The objective of Pre-Congestion Notification (PCN) is to protect the | The objective of Pre-Congestion Notification (PCN) is to protect the | |||
quality of service (QoS) of inelastic flows within a Diffserv domain. | quality of service (QoS) of inelastic flows within a Diffserv domain. | |||
The overall rate of the PCN-traffic is metered on every link in the | The overall rate of the PCN-traffic is metered on every link in the | |||
PCN domain, and PCN-packets are appropriately marked when certain | PCN domain, and PCN-packets are appropriately marked when certain | |||
configured rates are exceeded. Egress nodes pass information about | configured rates are exceeded. Egress nodes pass information about | |||
these PCN-marks to decision points which then decide whether to admit | these PCN-marks to decision points which then decide whether to admit | |||
or block new flow requests or to terminate some already-admitted | or block new flow requests or to terminate some already-admitted | |||
flows during serious pre-congestion. | flows during serious pre-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 provides for up to | codepoints within a PCN-domain. The PCN wire protocol for non-IP | |||
three different PCN marking states using a single DSCP: not-marked | protocol headers will need to be defined elsewhere. Nonetheless, | |||
(NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, | this document clarifies the PCN encoding for MPLS in an informational | |||
it is called the 3-in-1 PCN encoding. This document obsoletes | Appendix. The encoding for IP provides for up to three different PCN | |||
RFC5696. | marking states using a single DSCP: Not-marked (NM), Threshold-marked | |||
(ThM) and Excess-traffic-marked (ETM). Hence, it is called the | ||||
3-in-1 PCN encoding. This document obsoletes 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 September 12, 2012. | ||||
This Internet-Draft will expire on February 19, 2012. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | |||
1.2. Changes in This Version (to be removed by RFC Editor) . . 5 | 1.2. Changes in This Version (to be removed by RFC Editor) . . 5 | |||
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 7 | 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 7 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 8 | 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 8 | |||
3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 8 | 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 9 | |||
4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 9 | 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 10 | |||
4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 9 | 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 10 | |||
4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 10 | 4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 10 | |||
4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 10 | 4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 11 | |||
5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN | 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN | |||
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 11 | 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 11 | |||
5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 11 | 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 14 | |||
5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11 | 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 14 | |||
5.2.2. Behaviour of PCN-interior Nodes Using Two | 5.2.2. Behaviour of PCN-interior Nodes Using Two | |||
PCN-markings . . . . . . . . . . . . . . . . . . . . . 12 | PCN-markings . . . . . . . . . . . . . . . . . . . . . 14 | |||
5.2.3. Behaviour of PCN-interior Nodes Using One | 5.2.3. Behaviour of PCN-interior Nodes Using One | |||
PCN-marking . . . . . . . . . . . . . . . . . . . . . 12 | PCN-marking . . . . . . . . . . . . . . . . . . . . . 14 | |||
5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 13 | 5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 15 | |||
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13 | 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16 | |||
6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13 | 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 16 | |||
6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 14 | 6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 16 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15 | 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 17 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 16 | 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 | |||
Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 18 | Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 20 | |||
Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 19 | Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 21 | |||
Appendix C. Example Mapping between Encoding of PCN-Marks in | Appendix C. Example Mapping between Encoding of PCN-Marks in | |||
IP and in MPLS Shim Headers . . . . . . . . . . . . . 21 | IP and in MPLS Shim Headers . . . . . . . . . . . . . 24 | |||
Appendix D. Rationale for Difference Between the Schemes | Appendix D. Rationale for Difference Between the Schemes | |||
using One PCN-Marking . . . . . . . . . . . . . . . . 22 | using One PCN-Marking . . . . . . . . . . . . . . . . 25 | |||
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, | |||
skipping to change at page 4, line 42 | skipping to change at page 4, line 42 | |||
The encoding defined in [RFC5696] described how two PCN marking | The encoding defined in [RFC5696] described how two PCN marking | |||
states (Not-marked and PCN-Marked) could be encoded into the IP | states (Not-marked and PCN-Marked) could be encoded into the IP | |||
header using a single Diffserv codepoint. It defined 01 as an | header using a single Diffserv codepoint. It defined 01 as an | |||
experimental codepoint (EXP), along with guidelines for its use. Two | experimental codepoint (EXP), along with guidelines for its use. Two | |||
PCN marking states are sufficient for the Single Marking edge | PCN marking states are sufficient for the Single Marking edge | |||
behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However, PCN-domains | behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However, PCN-domains | |||
utilising the controlled load edge behaviour | utilising the controlled load edge behaviour | |||
[I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states. | [I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states. | |||
This document extends the RFC5696 encoding by redefining the | This document extends the RFC5696 encoding by redefining the | |||
experimental codepoint as a third PCN marking state in the IP header, | experimental codepoint as a third PCN marking state in the IP header, | |||
still using a single Diffserv codepoint. This encoding scheme is | but still using a single Diffserv codepoint. This encoding scheme is | |||
therefore called the "3-in-1 PCN encoding". It obsoletes the | therefore called the "3-in-1 PCN encoding". It obsoletes the | |||
[RFC5696] encoding, which provides only a sub-set of the same | [RFC5696] encoding, which provides only a sub-set of the same | |||
capabilities. | capabilities. | |||
The full version of this encoding requires any tunnel endpoint within | The full version of the 3-in-1 encoding requires any tunnel endpoint | |||
the PCN-domain to support the normal tunnelling rules defined in | within the PCN-domain to support the normal tunnelling rules defined | |||
[RFC6040]. There is one limited exception to this constraint where | in [RFC6040]. There is one limited exception to this constraint | |||
the PCN-domain only uses the excess-traffic-marking behaviour and | where the PCN-domain only uses the excess-traffic-marking behaviour | |||
where the threshold-marking behaviour is deactivated. This is | and where the threshold-marking behaviour is deactivated. This is | |||
discussed in Section 5.2.3.1. | discussed in Section 5.2.3.1. | |||
This document only concerns the PCN wire protocol encoding for IP | 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 will define the PCN wire | congestion response. Other documents will define the PCN wire | |||
protocol for other header types. Appendix C discusses a possible | protocol for other header types. Appendix C discusses a possible | |||
mapping between IP and MPLS. | mapping between IP and MPLS. | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
1.2. Changes in This Version (to be removed by RFC Editor) | 1.2. Changes in This Version (to be removed by RFC Editor) | |||
From draft-ietf-pcn-3-in-1-encoding-08 to -09: | ||||
* Added note about fail-safe to protect other traffic in the | ||||
event of tunnel misconfiguration. | ||||
* Changed section heading to be about applicability of | ||||
environments to the encoding, rather than the encoding to the | ||||
environments. | ||||
* Completely re-wrote PCN-ingress Node Behaviour section. | ||||
* Changed PCN interior node to PCN-node where the term was | ||||
intended to include all PCN-nodes. | ||||
* Clarified status of ECN/PCN co-existence appendix. Removed | ||||
inconsistent assertion in this appendix that an admission- | ||||
control DSCP alone can indicate that arriving traffic is PCN- | ||||
traffic. | ||||
* A few clarifying editorial amendments and updated refs. | ||||
From draft-ietf-pcn-3-in-1-encoding-07 to -08: Editorial corrections | From draft-ietf-pcn-3-in-1-encoding-07 to -08: Editorial corrections | |||
and clarifications. | and clarifications. | |||
From draft-ietf-pcn-3-in-1-encoding-06 to -07: | From draft-ietf-pcn-3-in-1-encoding-06 to -07: | |||
* Clarified that each operator not the IETF chooses which DSCP(s) | * Clarified that each operator not the IETF chooses which DSCP(s) | |||
are PCN-compatible, and made it unambiguous that only PCN-nodes | are PCN-compatible, and made it unambiguous that only PCN-nodes | |||
recognise that PCN-compatible DSCPs enable the 3-in-1 encoding. | recognise that PCN-compatible DSCPs enable the 3-in-1 encoding. | |||
* Removed statements about the PCN working group, given RFCs are | * Removed statements about the PCN working group, given RFCs are | |||
skipping to change at page 8, line 5 | skipping to change at page 8, line 24 | |||
metering function [RFC5670]. Abbreviated to ThM. | metering function [RFC5670]. Abbreviated to ThM. | |||
Excess-traffic-marked codepoint: a codepoint that indicates packets | Excess-traffic-marked codepoint: a codepoint that indicates packets | |||
that have been marked at a PCN-interior-node as a result of an | that have been marked at a PCN-interior-node as a result of an | |||
indication from the excess-traffic-metering function [RFC5670]. | indication from the excess-traffic-metering function [RFC5670]. | |||
Abbreviated to ETM. | Abbreviated to ETM. | |||
Not-marked codepoint: a codepoint that indicates PCN-packets that | Not-marked codepoint: a codepoint that indicates PCN-packets that | |||
are not PCN-marked. Abbreviated to NM. | are not PCN-marked. Abbreviated to NM. | |||
not-PCN codepoint: a codepoint that indicates packets that are not | Not-PCN codepoint: a codepoint that indicates packets that are not | |||
PCN-packets. | PCN-packets. | |||
2.2. List of Abbreviations | 2.2. List of Abbreviations | |||
The following abbreviations are used in this document: | The following abbreviations are used in this document: | |||
o AF = Assured Forwarding [RFC2597] | o AF = Assured Forwarding [RFC2597] | |||
o CE = Congestion Experienced [RFC3168] | o CE = Congestion Experienced [RFC3168] | |||
o CS = Class Selector [RFC2474] | o CS = Class Selector [RFC2474] | |||
o DSCP = Diffserv codepoint | o DSCP = Diffserv codepoint | |||
o e2e = end-to-end | ||||
o ECN = Explicit Congestion Notification [RFC3168] | o ECN = Explicit Congestion Notification [RFC3168] | |||
o ECT = ECN Capable Transport [RFC3168] | o ECT = ECN Capable Transport [RFC3168] | |||
o EF = Expedited Forwarding [RFC3246] | o EF = Expedited Forwarding [RFC3246] | |||
o ETM = Excess-traffic-marked | o ETM = Excess-traffic-marked | |||
o EXP = Experimental | o EXP = Experimental | |||
o IP = Internet protocol | ||||
o NM = Not-marked | o NM = Not-marked | |||
o PCN = Pre-Congestion Notification | o PCN = Pre-Congestion Notification | |||
o ThM = Threshold-marked | o ThM = Threshold-marked | |||
3. Definition of 3-in-1 PCN Encoding | 3. Definition of 3-in-1 PCN Encoding | |||
The 3-in-1 PCN encoding scheme allows for two or three PCN-marking | The 3-in-1 PCN encoding scheme supports networks that need three PCN- | |||
states to be encoded within the IP header. The full encoding is | marking states to be encoded within the IP header, as well as those | |||
shown in Figure 1. | that need only two. The full encoding is shown in Figure 1. | |||
+--------+----------------------------------------------------+ | +--------+----------------------------------------------------+ | |||
| | 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 1: 3-in-1 PCN Encoding | Figure 1: 3-in-1 PCN Encoding | |||
A PCN-node (i.e. a node within a PCN-domain) will be configured to | A PCN-node will be configured to recognise certain DSCPs as PCN- | |||
recognise certain DSCPs as PCN-compatible. Appendix A discusses the | compatible. Appendix A discusses the choice of suitable DSCPs. In | |||
choice of suitable DSCPs. In Figure 1 'DSCP n' indicates such a PCN- | Figure 1 'DSCP n' indicates such a PCN-compatible DSCP. In the PCN- | |||
compatible DSCP. Within the PCN-domain, any packet carrying a PCN- | domain, any packet carrying a PCN-compatible DSCP and with the ECN- | |||
compatible DSCP and with the ECN-field anything other than 00 (Not- | field anything other than 00 (Not-PCN) is a PCN-packet as defined in | |||
PCN) is a PCN-packet as defined in [RFC5559]. | [RFC5559]. | |||
PCN-nodes MUST interpret the ECN field of a PCN-packet using the | PCN-nodes MUST interpret the ECN field of a PCN-packet using the | |||
3-in-1 PCN encoding, rather than [RFC3168]. This does not change the | 3-in-1 PCN encoding, rather than [RFC3168]. This does not change the | |||
behaviour for any packet with a DSCP that is not PCN-compatible, or | behaviour for any packet with a DSCP that is not PCN-compatible, or | |||
for any node outside a PCN-domain. In all such cases the 3-in-1 | for any node outside a PCN-domain. In all such cases the 3-in-1 | |||
encoding is not applicable and so by default the node will interpret | encoding is not applicable and so by default the node will interpret | |||
the ECN field using [RFC3168]. | the ECN field using [RFC3168]. | |||
When using the 3-in-1 encoding, the codepoints of the ECN field have | When using the 3-in-1 encoding, the codepoints of the ECN field have | |||
the following meanings: | the following meanings: | |||
skipping to change at page 9, line 42 | skipping to change at page 10, line 15 | |||
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]. | |||
4. Requirements for and Applicability of 3-in-1 PCN Encoding | 4. Requirements for and Applicability of 3-in-1 PCN Encoding | |||
4.1. PCN Requirements | 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). All nodes in | |||
the PCN-domain may perform PCN-metering and -marking and mark PCN- | the PCN-domain perform PCN-metering and PCN-mark PCN-packets if | |||
packets if needed. There are two different metering and marking | needed. There are two different metering and marking behaviours: | |||
behaviours: threshold-marking and excess-traffic-marking [RFC5670]. | threshold-marking and excess-traffic-marking [RFC5670]. Some edge | |||
Some edge behaviors require only a single marking behaviour | behaviours 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 behaviour 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 use a PCN-compatible DSCP but do not use PCN-marking | packets that use a PCN-compatible DSCP but do not use PCN-marking | |||
(the not-PCN codepoint). | (the Not-PCN codepoint). | |||
In all current PCN edge behaviors that use two marking behaviours | In all current PCN edge behaviours 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. | |||
4.2. Requirements Imposed by Tunnelling | 4.2. Requirements Imposed by Tunnelling | |||
[RFC6040] defines rules for the encapsulation and decapsulation of | [RFC6040] defines rules for the encapsulation and decapsulation of | |||
ECN markings within IP-in-IP tunnels. The publication of RFC6040 | ECN markings within IP-in-IP tunnels. The publication of RFC6040 | |||
removed the tunnelling constraints that existed when the encoding of | removed the tunnelling constraints that existed when the encoding of | |||
[RFC5696] was written (see section 3.3.2 of | [RFC5696] was written (see section 3.3.2 of | |||
[I-D.ietf-pcn-encoding-comparison]). | [I-D.ietf-pcn-encoding-comparison]). | |||
Nonetheless, there is still a problem if there are any legacy (pre- | Nonetheless, there is still a problem if there are any legacy (pre- | |||
RFC6040) decapsulating tunnel endpoints within a PCN domain. If a | RFC6040) decapsulating tunnel endpoints within a PCN domain. If a | |||
PCN node Threshold-marks the outer header of a tunnelled packet that | PCN-node Threshold-marks the outer header of a tunnelled packet that | |||
has a Not-marked codepoint on the inner header, a legacy decapsulator | has a Not-marked codepoint on the inner header, a legacy decapsulator | |||
will forward the packet as Not-marked, losing the threshold marking. | will forward the packet as Not-marked, losing the Threshold-marking. | |||
The rules on applicability in Section 4.3 below are designed to avoid | The rules on applicability in Section 4.3 below are designed to avoid | |||
this problem. | this problem. | |||
4.3. Applicability of 3-in-1 PCN Encoding | Even if an operator accidentally breaks these applicability rules, | |||
the order of severity of the 3-in-1 codepoints was chosen to protect | ||||
other PCN or non-PCN traffic. Although legacy pre-RFC6040 tunnels | ||||
did not propagate '01', all tunnels pre-RFC6040 and post-RFC6040 have | ||||
always propagated '11' correctly. Therefore '11' was chosen to | ||||
signal the most severe pre-congestion (ETM), so it would act as a | ||||
reliable fail-safe even if an overlooked legacy tunnel was | ||||
suppressing 01 (ThM) signals. | ||||
4.3. Applicable Environments for the 3-in-1 PCN Encoding | ||||
The 3-in-1 encoding is applicable in situations where two marking | The 3-in-1 encoding is applicable in situations where two marking | |||
behaviours are being used in the PCN-domain. The 3-in-1 encoding can | behaviours are being used in the PCN-domain. The 3-in-1 encoding can | |||
also be used with only one marking behaviour, in which case one of | also be used with only one marking behaviour, in which case one of | |||
the codepoints MUST NOT be used throughout the PCN-domain (see | the codepoints MUST NOT be used anywhere in the PCN-domain (see | |||
Section 5.2.3). | Section 5.2.3). | |||
With one exception (see next paragraph), any tunnel endpoints | With one exception (see next paragraph), any tunnel endpoints | |||
(IP-in-IP and IPsec) within the PCN-domain MUST comply with the ECN | (IP-in-IP and IPsec) within the PCN-domain MUST comply with the ECN | |||
encapsulation and decapsulation rules set out in [RFC6040] (see | encapsulation and decapsulation rules set out in [RFC6040] (see | |||
Section 4.2). | Section 4.2). | |||
It may not be possible to upgrade every pre-RFC6040 tunnel endpoint | Operators may not be able to upgrade every pre-RFC6040 tunnel | |||
within a PCN-domain. In such circumstances a limited version of the | endpoint within a PCN-domain. In such circumstances a limited | |||
3-in-1 encoding can still be used but only under the following | version of the 3-in-1 encoding can still be used but only under the | |||
stringent condition. If any pre-RFC6040 tunnel endpoint exists | following stringent condition. If any pre-RFC6040 tunnel | |||
within a PCN-domain then every PCN-node in the PCN-domain MUST be | decapsulator exists within a PCN-domain then every PCN-node in the | |||
configured so that it never sets the ThM codepoint. PCN-interior | PCN-domain MUST be configured so that it never sets the ThM | |||
nodes in this case MUST solely use the Excess Traffic marking | codepoint. PCN-interior-nodes in this case MUST solely use the | |||
function, as defined in Section 5.2.3.1. In all other situations | Excess-traffic-marking function, as defined in Section 5.2.3.1. In | |||
where legacy tunnel endpoints might be present within the PCN domain, | all other situations where legacy tunnel decapsulators might be | |||
the 3-in-1 encoding is not applicable. | present within the PCN domain, the 3-in-1 encoding is not applicable. | |||
5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding | 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding | |||
Any tunnel endpoint implementation on a PCN-node MUST comply with | Any tunnel endpoint implementation on a PCN-node MUST comply with | |||
[RFC6040]. Since PCN is a new capability, this is considered a | [RFC6040]. Since PCN is a new capability, this is considered a | |||
reasonable requirement. | reasonable requirement. | |||
5.1. PCN-ingress Node Behaviour | 5.1. PCN-ingress Node Behaviour | |||
PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint. | Each ingress link into a PCN domain will apply the four functions | |||
To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are | described in section 4.2 of [RFC5559] to arriving packets. These | |||
already defined for use with admission-controlled traffic. | functions are applied in the following order: classify, police, PCN- | |||
Appendix A gives guidance to implementors on suitable DSCPs. | colour, meter. This section describes these four steps, but only the | |||
Guidelines for mixing traffic types within a PCN-domain are given in | aspects relevant to packet encoding: | |||
[RFC5670]. | ||||
If a packet arrives at the PCN-ingress-node that shares a PCN- | 1. Packet classification: The PCN-ingress-node determines whether | |||
compatible DSCP and is not a PCN-packet, the PCN-ingress-node MUST | each packet matches the filter spec of an admitted flow. Packets | |||
mark it as not-PCN. | that match are defined as PCN-packets. | |||
If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress-node | 1b. Extra step if ECN and PCN co-exist: If a packet classified as a | |||
MUST change the PCN codepoint to Not-marked. | PCN-packet arrives with the ECN field already set to a value other | |||
than Not-ECT (i.e. it is from an ECN-capable transport) then to | ||||
comply with BCP 124 [RFC4774] it MUST pass through one of the | ||||
following preparatory steps before the PCN-policing and PCN- | ||||
colouring steps. The choice between these four actions depends on | ||||
local policy: | ||||
If a PCN-packet arrives at the PCN-ingress-node with its ECN field | * Tunnel ECN-capable PCN-packets across the PCN-domain, using an | |||
already set to a value other than not-ECT, then appropriate action | RFC6040 tunnel. This tunnelling step MUST precede PCN-policing | |||
MUST be taken to meet the requirements of [RFC4774]. The simplest | and PCN-colouring so that the tunnel is logically outside the | |||
appropriate action is to just drop such packets. However, this is a | PCN domain (see Appendix B and specifically Figure 2). | |||
drastic action that an operator may feel is undesirable. Appendix B | ||||
provides more information and summarises other alternative actions | This tunnelling policy is the RECOMMENDED choice, and | |||
that might be taken. | implementations SHOULD use it as the default. | |||
* If tunnelling is not possible, the PCN-ingress-node can allow | ||||
through ECN-capable packets without tunnelling, but it MUST | ||||
drop CE-marked packets at this stage. Failure to drop CE would | ||||
risk congestion collapse, because without a tunnel there is no | ||||
mechanism to propagate the CE markings across the PCN-domain | ||||
(see Appendix B). | ||||
This policy is emphatically NOT RECOMMENDED because there is no | ||||
tunnel to protect the e2e ECN capability, which is otherwise | ||||
disabled when the PCN-egress-node zeroes the ECN field. | ||||
* Drop the packet. | ||||
This policy is also emphatically NOT RECOMMENDED, because it | ||||
precludes the possibility that e2e ECN can co-exist with PCN as | ||||
a means of controlling congestion. | ||||
* Any other action that complies with [RFC4774] (see Appendix B | ||||
for an example). | ||||
Appendix B provides more information about the co-existence of PCN | ||||
and ECN. | ||||
2. PCN-Policing: The PCN-policing function only allows appropriate | ||||
packets into the PCN behaviour aggregate. Per-flow policing | ||||
actions may be required, but these are specified in the relevant | ||||
edge-behaviour document, e.g. [I-D.ietf-pcn-sm-edge-behaviour], | ||||
[I-D.ietf-pcn-cl-edge-behaviour]. | ||||
Here we only specify packet-level PCN-policing, which prevents | ||||
packets that are not PCN-packets from being forwarded into the | ||||
PCN-domain if PCN-interior-nodes would otherwise mistake them for | ||||
PCN-packets. A non-PCN-packet will be confused with a PCN-packet | ||||
if on arrival it meets all three of the following conditions: | ||||
a) it is not classified as a PCN-packet | ||||
b) it already carries a PCN-compatible DSCP | ||||
c) its ECN field carries a codepoint other than Not-ECT. | ||||
The PCN-ingress-node MUST police packets that meet all three | ||||
conditions (a-c) by subjecting them to one of the following | ||||
treatments: | ||||
* re-mark the DSCP to a DSCP that is not PCN-compatible; | ||||
* tunnel the packet to the PCN-egress with a DSCP in the outer | ||||
header that is not PCN-compatible; | ||||
* drop the packet (NOT RECOMMENDED--see below). | ||||
The choice between these actions depends on local policy. In the | ||||
absence of any operator-specific configuration for this case, by | ||||
default an implementation SHOULD re-mark the DSCP to zero. | ||||
Traffic that meets all three of the above conditions (a-c) is not | ||||
PCN-traffic, therefore ideally a PCN-ingress ought not to | ||||
interfere with it, but it has to do something to avoid ambiguous | ||||
packet markings. Clearing the ECN field is not an appropriate | ||||
policing action, because a network node ought not to interfere | ||||
with an e2e signal. Even if such packets seem like an attack, | ||||
drop would be overkill, because such an attack can be neutralised | ||||
by just re-marking the DSCP. And DSCP re-marking in the network | ||||
is legitimate, because the DSCP is not considered an e2e signal. | ||||
3. PCN-colouring: If a packet has been classified as a PCN-packet, | ||||
once it has been policed, the PCN-ingress-node: | ||||
* MUST set a PCN-compatible Diffserv codepoint on all PCN- | ||||
packets. 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. | ||||
* MUST set the PCN codepoint of all PCN-packets to Not-marked | ||||
(NM). | ||||
4. PCN rate-metering: This fourth step may be necessary depending on | ||||
the edge-behaviour in force. It is listed for completeness, but | ||||
it is not relevant to this encoding document. | ||||
5.2. PCN-interior Node Behaviour | 5.2. PCN-interior Node Behaviour | |||
5.2.1. Behaviour Common to all PCN-interior Nodes | 5.2.1. Behaviour Common to all PCN-interior Nodes | |||
Interior nodes MUST NOT change not-PCN to any other codepoint. | Interior nodes MUST NOT change Not-PCN to any other codepoint. | |||
Interior nodes MUST NOT change NM to not-PCN. | Interior nodes MUST NOT change NM to Not-PCN. | |||
Interior nodes MUST NOT change ThM to NM or not-PCN. | Interior nodes MUST NOT change ThM to NM or Not-PCN. | |||
Interior nodes MUST NOT change ETM to any other codepoint. | Interior nodes MUST NOT change ETM to any other codepoint. | |||
5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings | 5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings | |||
If the threshold-meter function indicates a need to mark a packet, | If the threshold-meter function indicates a need to mark a packet, | |||
the PCN-interior node MUST change NM to ThM. | the PCN-interior-node MUST change NM to ThM. | |||
If the excess-traffic-meter function indicates a need to mark a | If the excess-traffic-meter function indicates a need to mark a | |||
packet: | packet: | |||
o the PCN-interior node MUST change NM to ETM; | o the PCN-interior-node MUST change NM to ETM; | |||
o the PCN-interior node MUST change ThM to ETM. | o the PCN-interior-node MUST change ThM to ETM. | |||
If both the threshold meter and the excess-traffic meter indicate the | If both the threshold meter and the excess-traffic meter indicate the | |||
need to mark a packet, the Excess-traffic-marking rules MUST take | need to mark a packet, the Excess-traffic-marking rules MUST take | |||
precedence. | precedence. | |||
5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking | 5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking | |||
Some PCN edge behaviours require only one PCN-marking within the PCN- | Some PCN edge behaviours require only one PCN-marking within the PCN- | |||
domain. The Single Marking edge behaviour | domain. The Single Marking edge behaviour | |||
[I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark | [I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior-nodes to mark | |||
packets using the excess-traffic-meter function [RFC5670]. It is | packets using the excess-traffic-meter function [RFC5670]. It is | |||
possible that future schemes may require only the threshold-meter | possible that future schemes may require only the threshold-meter | |||
function. Appendix D explains the rationale for the behaviours | function. Appendix D explains the rationale for the behaviours | |||
defined in this section. | defined in this section. | |||
5.2.3.1. Marking Using only the Excess-traffic-meter Function | 5.2.3.1. Marking Using only the Excess-traffic-meter Function | |||
The threshold-traffic-meter function SHOULD be disabled and MUST NOT | The threshold-traffic-meter function SHOULD be disabled and MUST NOT | |||
trigger any packet marking. | trigger any packet marking. | |||
The PCN-interior node SHOULD raise a management alarm if it receives | The PCN-interior-node SHOULD raise a management alarm if it receives | |||
a ThM packet, but the frequency of such alarms SHOULD be limited. | a ThM packet, but the frequency of such alarms SHOULD be limited. | |||
If the excess-traffic-meter function indicates a need to mark the | If the excess-traffic-meter function indicates a need to mark the | |||
packet: | packet: | |||
o the PCN-interior node MUST change NM to ETM; | o the PCN-interior-node MUST change NM to ETM; | |||
o the PCN-interior node MUST change ThM to ETM. It SHOULD also | o the PCN-interior-node MUST change ThM to ETM. It SHOULD also | |||
raise an alarm as above. | raise an alarm as above. | |||
5.2.3.2. Marking using only the Threshold-meter Function | 5.2.3.2. Marking using only the Threshold-meter Function | |||
The excess-traffic-meter function SHOULD be disabled and MUST NOT | The excess-traffic-meter function SHOULD be disabled and MUST NOT | |||
trigger any packet marking. | trigger any packet marking. | |||
The PCN-interior node SHOULD raise a management alarm if it receives | The PCN-interior-node SHOULD raise a management alarm if it receives | |||
an ETM packet, but the frequency of such alarms SHOULD be limited. | an ETM packet, but the frequency of such alarms SHOULD be limited. | |||
If the threshold-meter function indicates a need to mark the packet: | If the threshold-meter function indicates a need to mark the packet: | |||
o the PCN-interior node MUST change NM to ThM; | o the PCN-interior-node MUST change NM to ThM; | |||
o the PCN-interior node MUST NOT change ETM to any other codepoint. | o the PCN-interior-node MUST NOT change ETM to any other codepoint. | |||
It SHOULD raise an alarm as above if it encounters an ETM packet. | It SHOULD raise an alarm as above if it encounters an ETM packet. | |||
5.3. PCN-egress Node Behaviour | 5.3. PCN-egress Node Behaviour | |||
A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all | A PCN-egress-node SHOULD set the Not-PCN (00) codepoint on all | |||
packets it forwards out of the PCN-domain. | packets it forwards out of the PCN-domain. | |||
The only exception to this is if the PCN-egress-node is certain that | The only exception to this is if the PCN-egress-node is certain that | |||
revealing other codepoints outside the PCN-domain won't contravene | revealing other codepoints outside the PCN-domain won't contravene | |||
the guidance given in [RFC4774]. For instance, if the PCN-ingress- | the guidance given in [RFC4774]. For instance, if the PCN-ingress- | |||
node has explicitly informed the PCN-egress-node that this flow is | node has explicitly informed the PCN-egress-node that this flow is | |||
ECN-capable, then it might be safe to expose other codepoints. | ECN-capable, then it might be safe to expose other ECN codepoints. | |||
Appendix B gives details of how such schemes might work, but such | Appendix B gives details of how such schemes might work, but such | |||
schemes are currently only tentative ideas. | schemes are currently only tentative ideas. | |||
If the PCN-domain is configured to use only excess-traffic marking, | If the PCN-domain is configured to use only Excess-traffic-marking, | |||
the PCN-egress node MUST treat ThM as ETM and, if only threshold- | the PCN-egress-node MUST treat ThM as ETM and, if only threshold- | |||
marking is used, it SHOULD treat ETM as ThM. However it SHOULD raise | marking is used, it SHOULD treat ETM as ThM. However it SHOULD raise | |||
a management alarm in either instance since this means there is some | a management alarm in either case since this means there is some | |||
misconfiguration in the PCN-domain. | misconfiguration in the PCN-domain. | |||
6. Backward Compatibility | 6. Backward Compatibility | |||
6.1. Backward Compatibility with ECN | 6.1. Backward Compatibility with ECN | |||
BCP 124 [RFC4774] gives guidelines for specifying alternative | BCP 124 [RFC4774] gives guidelines for specifying alternative | |||
semantics for the ECN field. It sets out a number of factors to be | semantics for the ECN field. It sets out a number of factors to be | |||
taken into consideration. It also suggests various techniques to | taken into consideration. It also suggests various techniques to | |||
allow the co-existence of default ECN and alternative ECN semantics. | allow the co-existence of default ECN and alternative ECN semantics. | |||
The encoding specified in this document uses one of those techniques; | The encoding specified in this document uses one of those techniques; | |||
it defines PCN-compatible Diffserv codepoints as no longer supporting | it defines PCN-compatible Diffserv codepoints as no longer supporting | |||
the default ECN semantics within a PCN domain. As such, this | the default ECN semantics within a PCN domain. As such, this | |||
document is compatible with BCP 124. | document is compatible with BCP 124. | |||
On its own, the 3-in-1 encoding cannot support both ECN marking end- | There is not enough space in one IP header for the 3-in-1 encoding to | |||
to-end (e2e) and PCN-marking within a PCN-domain. Appendix B | support both ECN marking end-to-end and PCN-marking within a PCN- | |||
discusses possible ways to do this, e.g. by carrying e2e ECN across a | domain. The non-normative Appendix B discusses possible ways to do | |||
PCN-domain within the inner header of an IP-in-IP tunnel. Although | this, e.g. by carrying e2e ECN across a PCN-domain within the inner | |||
Appendix B recommends various approaches over others, it is merely | header of an IP-in-IP tunnel. The normative text in Section 5.1 | |||
informative and all such schemes are beyond the normative scope of | requires one of these methods to be configured at the PCN-ingress- | |||
this document. | node and recommends that implementations offer tunnelling as the | |||
default. | ||||
In any PCN deployment, traffic can only enter the PCN-domain through | In any PCN deployment, traffic can only enter the PCN-domain through | |||
PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress- | PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress- | |||
nodes ensure that any packets entering the PCN-domain have the ECN | nodes ensure that any packets entering the PCN-domain have the ECN | |||
field in their outermost IP header set to the appropriate codepoint. | field in their outermost IP header set to the appropriate codepoint. | |||
PCN-egress-nodes then guarantee that the ECN field of any packet | PCN-egress-nodes then guarantee that the ECN field of any packet | |||
leaving the PCN-domain has appropriate ECN semantics. This prevents | leaving the PCN-domain has appropriate ECN semantics. This prevents | |||
unintended leakage of ECN marks into or out of the PCN-domain, and | unintended leakage of ECN marks into or out of the PCN-domain, and | |||
thus reduces backward-compatibility issues. | thus reduces backward-compatibility issues. | |||
6.2. Backward Compatibility with the RFC5696 Encoding | 6.2. Backward Compatibility with the RFC5696 Encoding | |||
A PCN node implemented to use the obsoleted RFC5696 encoding could | A PCN-node implemented to use the obsoleted RFC5696 encoding could | |||
conceivably have been configured so that the Threshold-meter function | conceivably have been configured so that the Threshold-meter function | |||
marked what is now defined as the ETM codepoint in the 3-in-1 | marked what is now defined as the ETM codepoint in the 3-in-1 | |||
encoding. However, there is no known deployment of such an | encoding. However, there is no known deployment of this rather | |||
implementation and no reason to believe that such an implementation | unlikely variant of RFC5696 and no reason to believe that such an | |||
would ever have been built. Therefore, it seems safe to ignore this | implementation would ever have been built. Therefore, it seems safe | |||
issue. | 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 | |||
skipping to change at page 15, line 19 | skipping to change at page 17, line 43 | |||
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. | |||
In general, the use of this PCN encoding scheme presupposes that any | In general, the use of this PCN encoding scheme presupposes that any | |||
tunnel endpoints within the PCN-domain comply with [RFC6040]. | tunnel endpoints within the PCN-domain comply with [RFC6040]. | |||
10. Acknowledgements | 10. Acknowledgements | |||
Many thanks to Phil Eardley for providing extensive feedback, | Many thanks to Philip Eardley for providing extensive feedback, | |||
criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan, | criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan, | |||
Ruediger Geib, Georgios Karaginannis and everyone else who has | Ruediger Geib, Georgios Karagiannis, Adrian Farrel and everyone else | |||
commented on the document. | 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 16, line 25 | skipping to change at page 18, line 49 | |||
Notification", RFC 6040, | Notification", RFC 6040, | |||
November 2010. | November 2010. | |||
12.2. Informative References | 12.2. Informative References | |||
[I-D.ietf-pcn-cl-edge-behaviour] Charny, A., Huang, F., | [I-D.ietf-pcn-cl-edge-behaviour] Charny, A., Huang, F., | |||
Karagiannis, G., Menth, M., and | Karagiannis, G., Menth, M., and | |||
T. Taylor, "PCN Boundary Node | T. Taylor, "PCN Boundary Node | |||
Behaviour for the Controlled Load | Behaviour for the Controlled Load | |||
(CL) Mode of Operation", draft- | (CL) Mode of Operation", draft- | |||
ietf-pcn-cl-edge-behaviour-09 | ietf-pcn-cl-edge-behaviour-12 | |||
(work in progress), June 2011. | (work in progress), | |||
February 2012. | ||||
[I-D.ietf-pcn-encoding-comparison] Karagiannis, G., Chan, K., | [I-D.ietf-pcn-encoding-comparison] Karagiannis, G., Chan, K., | |||
Moncaster, T., Menth, M., | Moncaster, T., Menth, M., | |||
Eardley, P., and B. Briscoe, | Eardley, P., and B. Briscoe, | |||
"Overview of Pre-Congestion | "Overview of Pre-Congestion | |||
Notification Encoding", draft- | Notification Encoding", draft- | |||
ietf-pcn-encoding-comparison-06 | ietf-pcn-encoding-comparison-09 | |||
(work in progress), June 2011. | (work in progress), March 2012. | |||
[I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., | [I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., | |||
Menth, M., and T. Taylor, "PCN | Menth, M., and T. Taylor, "PCN | |||
Boundary Node Behaviour for the | Boundary Node Behaviour for the | |||
Single Marking (SM) Mode of | Single Marking (SM) Mode of | |||
Operation", draft-ietf-pcn-sm- | Operation", draft-ietf-pcn-sm- | |||
edge-behaviour-06 (work in | edge-behaviour-09 (work in | |||
progress), June 2011. | progress), February 2012. | |||
[RFC2597] Heinanen, J., Baker, F., Weiss, | [RFC2597] Heinanen, J., Baker, F., Weiss, | |||
W., and J. Wroclawski, "Assured | W., and J. Wroclawski, "Assured | |||
Forwarding PHB Group", RFC 2597, | Forwarding PHB Group", RFC 2597, | |||
June 1999. | June 1999. | |||
[RFC3246] Davie, B., Charny, A., Bennet, | [RFC3246] Davie, B., Charny, A., Bennet, | |||
J., Benson, K., Le Boudec, J., | J., Benson, K., Le Boudec, J., | |||
Courtney, W., Davari, S., Firoiu, | Courtney, W., Davari, S., Firoiu, | |||
V., and D. Stiliadis, "An | V., and D. Stiliadis, "An | |||
skipping to change at page 18, line 47 | skipping to change at page 21, line 20 | |||
mechanism for traffic with a high degree of statistical multiplexing. | mechanism for traffic with a high degree of statistical multiplexing. | |||
PCN-marking would therefore be appropriate to apply to traffic in the | PCN-marking would therefore be appropriate to apply to traffic in the | |||
above classes, but only within a PCN-domain containing sufficiently | above classes, but only within a PCN-domain containing sufficiently | |||
aggregated traffic. In such cases, the above service classes may | aggregated traffic. In such cases, the above service classes may | |||
well all be subject to a single forwarding treatment (treatment | well all be subject to a single forwarding treatment (treatment | |||
aggregate [RFC5127]). However, this does not imply all such IP | aggregate [RFC5127]). However, this does not imply all such IP | |||
traffic would necessarily be identified by one DSCP -- each service | traffic would necessarily be identified by one DSCP -- each service | |||
class might keep a distinct DSCP within the highly aggregated region | class might keep a distinct DSCP within the highly aggregated region | |||
[RFC5127]. | [RFC5127]. | |||
Guidelines for conserving DSCPs by allowing non-admission-controlled- | ||||
traffic to compete with PCN-traffic are given in Appendix B.1 of | ||||
[RFC5670]. | ||||
Additional service classes may be defined for which admission control | Additional service classes may be defined for which admission control | |||
is appropriate, whether through some future standards action or | is appropriate, whether through some future standards action or | |||
through local use by certain operators, e.g., the Multimedia | through local use by certain operators, e.g., the Multimedia | |||
Streaming service class (AF3). This document does not preclude the | Streaming service class (AF3). This document does not preclude the | |||
use of PCN in more cases than those listed above. | use of PCN in more cases than those listed above. | |||
Note: The above discussion is informative not normative, as operators | Note: The above discussion is informative not normative, as operators | |||
are ultimately free to decide whether to use admission control for | are ultimately free to decide whether to use admission control for | |||
certain service classes and whether to use PCN as their mechanism of | certain service classes and whether to use PCN as their mechanism of | |||
choice. | choice. | |||
Appendix B. Co-existence of ECN and PCN | Appendix B. Co-existence of ECN and PCN | |||
This appendix is informative, not normative. | This appendix is informative, not normative. It collects together | |||
material relevant to co-existence of ECN and PCN, including that | ||||
spread throughout the body of this specification. If this results in | ||||
any conflict or ambiguity, the normative text in the body of the | ||||
specification takes precedence. | ||||
The PCN encoding described in this document re-uses the bits of the | ECN [RFC3168] is an e2e congestion notification mechanism. As such | |||
ECN field in the IP header. Consequently, this disables ECN within | it is possible that some traffic entering the PCN-domain may also be | |||
the PCN domain. Appendix B of [RFC5696] (obsoleted) included advice | ECN-capable. The PCN encoding described in this document re-uses the | |||
on handling ECN traffic within a PCN-domain. This appendix | bits of the ECN field in the IP header. Consequently, this disables | |||
reiterates and clarifies that advice. | ECN within the PCN domain. | |||
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 (PCN-traffic) and non-admission-controlled traffic (non-PCN- | |||
traffic). | ||||
Admission-controlled traffic will be re-marked to a PCN-compatible | ||||
DSCP by the PCN-ingress-node. Two mechanisms can be used to identify | ||||
such traffic: | ||||
a. Flow signalling, which associates a filterspec with a need for | ||||
admission control (e.g. through RSVP or some equivalent message, | ||||
e.g. from a SIP server to the ingress); the PCN-ingress-node re- | ||||
marks traffic matching that filterspec to a PCN-compatible DSCP. | ||||
b. Traffic arrives with a DSCP that implies it requires admission | Flow signalling identifies admission controlled traffic, by | |||
control such as VOICE-ADMIT [RFC5865] or Real-Time Interactive, | associating a filterspec with the need for admission control (e.g. | |||
Broadcast Video when used for video on demand, and multimedia | through RSVP or some equivalent message, e.g. from a SIP server to | |||
conferencing [RFC4594][RFC5865] (see Appendix A). | the ingress or from a logically centralised network control system). | |||
The PCN-ingress-node re-marks admission-conrolled traffic matching | ||||
that filterspec to a PCN-compatible DSCP. Note that the term flow | ||||
need not imply just one microflow, but instead could match an | ||||
aggregate and/or could depend on the incoming DSCP (see Appendix A). | ||||
All other traffic can be thought of as non-admission-controlled (and | All other traffic can be thought of as non-admission-controlled (and | |||
therefore outside the scope of PCN). However such traffic may still | therefore outside the scope of PCN). However such traffic may still | |||
need to share the same DSCP as the admission-controlled traffic. | need to share the same DSCP as the admission-controlled traffic. | |||
This may be due to policy (for instance if it is high priority voice | This may be due to policy (for instance if it is high priority voice | |||
traffic), or may be because 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 | ||||
such it is possible that some traffic entering the PCN-domain may | ||||
also be ECN capable. | ||||
Unless specified otherwise, for any of the cases in the list below, | 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 | an IP-in-IP tunnel that complies with[RFC6040] can be used to | |||
PCN domain. The tunnelling action should be applied wholly outside | preserve ECN markings across the PCN domain. The tunnelling action | |||
the PCN-domain as illustrated in the following figure: | should be applied wholly outside the PCN-domain as illustrated in | |||
Figure 2. Then, by the rules of RFC6040, the tunnel egress | ||||
propagates the ECN field from the inner header, because the PCN- | ||||
egress will have zeroed the outer ECN field. | ||||
, . . . . . PCN-domain . . . . . . | , . . . . . PCN-domain . . . . . . | |||
. ,--------. ,--------. . | . ,--------. ,--------. . | |||
. _| PCN- |___________________| PCN- |_ . | . _| PCN- |___________________| PCN- |_ . | |||
. / | ingress | | egress | \ . | . / | ingress | | egress | \ . | |||
.| '---------' '--------' |. | .| '---------' '--------' |. | |||
| . . . . . . . . . . . . . . .| | | . . . . . . . . . . . . . . .| | |||
,--------. ,--------. | ,--------. ,--------. | |||
_____| Tunnel | | Tunnel |____ | _____| Tunnel | | Tunnel |____ | |||
| Ingress | - - ECN preserved inside tunnel - - | Egress | | | Ingress | - - ECN preserved inside tunnel - - | Egress | | |||
'---------' '--------' | '---------' '--------' | |||
Figure 2: Separation of tunnelling and PCN actions | Figure 2: Separation of tunnelling and PCN actions | |||
There are three cases for how e2e ECN traffic may wish to be treated | There are three cases for how e2e ECN traffic may wish to be treated | |||
while crossing a PCN domain: | while crossing a PCN domain: | |||
a) Traffic that does not require admission control: | a) Traffic that does not require PCN admission control: | |||
For example, traffic that does not match flow signaling being used | For example, traffic that does not match flow signaling being used | |||
for admission control. In this case the e2e ECN traffic is not | for admission control. In this case the e2e ECN traffic is not | |||
treated as PCN-traffic. There are two possible scenarios: | treated as PCN-traffic. There are two possible scenarios: | |||
* Arriving traffic does not carry a PCN-compatible DSCP: no | * Arriving traffic does not carry a PCN-compatible DSCP: no | |||
action required. | action required. | |||
* Arriving traffic carries a DSCP that clashes with a PCN- | * Arriving traffic carries a DSCP that clashes with a PCN- | |||
compatible DSCP. There are two options: | compatible DSCP. There are two options: | |||
1. The ingress maps the DSCP to a local DSCP with the same | 1. The ingress maps the DSCP to a local DSCP with the same | |||
scheduling PHB as the original DSCP, and the egress re-maps | scheduling PHB as the original DSCP, and the egress re-maps | |||
it to the original PCN-compatible DSCP. | it to the original PCN-compatible DSCP. | |||
2. The ingress tunnels the traffic, setting not-PCN in the | 2. The ingress tunnels the traffic, setting the DSCP in the | |||
outer header; note that this turns off ECN for this traffic | outer header to a local DSCP with the same scheduling PHB | |||
within the PCN domain. | as the original DSCP. | |||
The first option is recommended unless the operator is short of | 3. The ingress tunnels the traffic, using the original DSCP in | |||
local DSCPs. | the outer but setting Not-PCN in the outer header; note | |||
that this turns off ECN for this traffic within the PCN | ||||
domain. | ||||
The first or second options are recommended unless the operator | ||||
is short of local DSCPs. | ||||
b) Traffic that requires admission-control: | b) Traffic that requires admission-control: | |||
In this case the e2e ECN traffic is treated as PCN-traffic across | In this case the e2e ECN traffic is treated as PCN-traffic across | |||
the PCN domain. There are two options. | the PCN domain. There are two options. | |||
* The PCN-ingress-node places this traffic in a tunnel with a | * The PCN-ingress-node places this traffic in a tunnel with a | |||
PCN-compatible DSCP in the outer header. The PCN-egress zeroes | PCN-compatible DSCP in the outer header. The PCN-egress zeroes | |||
the ECN-field before decapsulation. | the ECN-field before decapsulation. | |||
* The PCN-ingress-node drops CE-marked packets and otherwise sets | * The PCN-ingress-node drops CE-marked packets and otherwise sets | |||
skipping to change at page 21, line 4 | skipping to change at page 23, line 34 | |||
b) Traffic that requires admission-control: | b) Traffic that requires admission-control: | |||
In this case the e2e ECN traffic is treated as PCN-traffic across | In this case the e2e ECN traffic is treated as PCN-traffic across | |||
the PCN domain. There are two options. | the PCN domain. There are two options. | |||
* The PCN-ingress-node places this traffic in a tunnel with a | * The PCN-ingress-node places this traffic in a tunnel with a | |||
PCN-compatible DSCP in the outer header. The PCN-egress zeroes | PCN-compatible DSCP in the outer header. The PCN-egress zeroes | |||
the ECN-field before decapsulation. | the ECN-field before decapsulation. | |||
* The PCN-ingress-node drops CE-marked packets and otherwise sets | * The PCN-ingress-node drops CE-marked packets and otherwise sets | |||
the ECN-field to NM and sets the DCSP to a PCN-compatible DSCP. | the ECN-field to NM and sets the DCSP to a PCN-compatible DSCP. | |||
The PCN-egress zeroes the ECN field of all PCN packets; note | The PCN-egress zeroes the ECN field of all PCN packets; note | |||
that this turns off e2e ECN. | that this turns off e2e ECN. | |||
The second option is emphatically not recommended, unless perhaps | The second option is emphatically not recommended, unless perhaps | |||
as a last resort if tunnelling is not possible for some | as a last resort if tunnelling is not possible for some | |||
insurmountable reason. | insurmountable reason. | |||
c) Traffic that requires admission control where the endpoints ask to | c) Traffic that requires PCN admission control where the endpoints | |||
see PCN marks: | ask to see PCN marks: | |||
Note that this scheme is currently only a tentative idea. | Note that this scheme is currently only a tentative idea. | |||
For real-time data generated by an adaptive codec, schemes have | For real-time data generated by an adaptive codec, schemes have | |||
been suggested where PCN marks may be leaked out of the PCN-domain | been suggested where PCN marks may be leaked out of the PCN-domain | |||
so that end hosts can drop to a lower data rate, thus deferring | so that end hosts can drop to a lower data-rate, thus deferring | |||
the need for admission control. Currently such schemes require | the need for admission control. Currently such schemes require | |||
further study and the following is for guidance only. | further study and the following is for guidance only. | |||
The PCN-ingress-node needs to tunnel the traffic as in Figure 2, | The PCN-ingress-node needs to tunnel the traffic as in Figure 2, | |||
taking care to comply with [RFC6040]. In this case the PCN-egress | taking care to comply with [RFC6040]. In this case the PCN-egress | |||
does not zero the ECN field contrary to the recommendation in | does not zero the ECN field contrary to the recommendation in | |||
Section 5.3, so that the [RFC6040] tunnel egress will preserve any | Section 5.3, so that the [RFC6040] tunnel egress will preserve any | |||
PCN-marking. Note that a PCN interior node may change the ECN- | PCN-marking. Note that a PCN-interior-node may change the ECN- | |||
field from 10 to 01 (NM to ThM), which would be interpreted by the | field from 10 to 01 (NM to ThM), which would be interpreted by the | |||
e2e ECN as a change from ECT(0) into ECT(1). This would not be | e2e ECN as a change from ECT(0) into ECT(1). This would not be | |||
compatible with the (currently experimental) ECN nonce [RFC3540]. | compatible with the (currently experimental) ECN nonce [RFC3540]. | |||
Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in | Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in | |||
MPLS Shim Headers | MPLS Shim Headers | |||
This appendix is informative not normative. | This appendix is informative not normative. | |||
The 6 bits of the DS field in the IP header provide for 64 | The 6 bits of the DS field in the IP header provide for 64 | |||
skipping to change at page 22, line 33 | skipping to change at page 25, line 14 | |||
In either case, if the operator wishes to support the same Diffserv | 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 | 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 | site-local mapping to an MPLS TC codepoint for IP headers marked | |||
with: | with: | |||
o DSCP n and Not-PCN | o DSCP n and Not-PCN | |||
The above sets of codepoints are required for every PCN-compatible | The above sets of codepoints are required for every PCN-compatible | |||
DSCP. Clearly, given so few TC codepoints are available, it may be | DSCP. Clearly, given so few TC codepoints are available, it may be | |||
necessary to compromise by merging together some capabilities. | necessary to compromise by merging together some capabilities. | |||
Guidelines for conserving TC codepoints by allowing non-admission- | ||||
controlled-traffic to compete with PCN-traffic are given in Appendix | ||||
B.1 of [RFC5670]. | ||||
Appendix D. Rationale for Difference Between the Schemes using One PCN- | Appendix D. Rationale for Difference Between the Schemes using One PCN- | |||
Marking | Marking | |||
Readers may notice a difference between the two behaviours in | Readers may notice a difference between the two behaviours in | |||
Section 5.2.3.1 and Section 5.2.3.2. With only excess-traffic | Section 5.2.3.1 and Section 5.2.3.2. With only Excess-traffic- | |||
marking enabled, an unexpected ThM packet can be re-marked to ETM. | marking enabled, an unexpected ThM packet can be re-marked to ETM. | |||
However, with only Threshold-marking, an unexpected ETM packet cannot | However, with only Threshold-marking, an unexpected ETM packet cannot | |||
be re-marked to ThM. | be re-marked to ThM. | |||
This apparent inconsistency is deliberate. The behaviour with only | This apparent inconsistency is deliberate. The behaviour with only | |||
threshold marking keeps to the rule of Section 5.2.1 that ETM is more | Threshold-marking keeps to the rule of Section 5.2.1 that ETM is more | |||
severe and must never be changed to ThM even though ETM is not a | severe and must never be changed to ThM even though ETM is not a | |||
valid marking in this case. Otherwise implementations would have to | valid marking in this case. Otherwise implementations would have to | |||
allow operators to configure an exception to this rule, which would | allow operators to configure an exception to this rule, which would | |||
not be safe practice and would require different code in the data | not be safe practice and would require different code in the data- | |||
plane compared to the common behaviour. | plane compared to the common behaviour. | |||
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. 79 change blocks. | ||||
177 lines changed or deleted | 307 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/ |