draft-ietf-pcn-3-in-1-encoding-11.txt | rfc6660.txt | |||
---|---|---|---|---|
Congestion and Pre-Congestion B. Briscoe | Internet Engineering Task Force (IETF) B. Briscoe | |||
Notification BT | Request for Comments: 6660 BT | |||
Internet-Draft T. Moncaster | Obsoletes: 5696 T. Moncaster | |||
Obsoletes: 5696 (if approved) Moncaster Internet Consulting | Category: Standards Track University of Cambridge | |||
Intended status: Standards Track M. Menth | ISSN: 2070-1721 M. Menth | |||
Expires: October 19, 2012 University of Tuebingen | University of Tuebingen | |||
April 17, 2012 | July 2012 | |||
Encoding 3 PCN-States in the IP header using a single DSCP | Encoding Three Pre-Congestion Notification (PCN) States | |||
draft-ietf-pcn-3-in-1-encoding-11 | in the IP Header Using a Single Diffserv Codepoint (DSCP) | |||
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 PCN-traffic is metered on every link in the PCN- | |||
PCN domain, and PCN-packets are appropriately marked when certain | 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 that 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 reusing the Explicit Congestion Notification (ECN) | |||
codepoints within a PCN-domain. The PCN wire protocol for non-IP | codepoints within a PCN-domain. The PCN wire protocol for non-IP | |||
protocol headers will need to be defined elsewhere. Nonetheless, | protocol headers will need to be defined elsewhere. Nonetheless, | |||
this document clarifies the PCN encoding for MPLS in an informational | this document clarifies the PCN encoding for MPLS in an informational | |||
Appendix. The encoding for IP provides for up to three different PCN | appendix. The encoding for IP provides for up to three different PCN | |||
marking states using a single DSCP: Not-marked (NM), Threshold-marked | marking states using a single Diffserv codepoint (DSCP): not-marked | |||
(ThM) and Excess-traffic-marked (ETM). Hence, it is called the | (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). | |||
3-in-1 PCN encoding. This document obsoletes RFC5696. | Hence, it is called the 3-in-1 PCN encoding. This document obsoletes | |||
RFC 5696. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | This document is a product of the Internet Engineering Task Force | |||
Task Force (IETF). Note that other groups may also distribute | (IETF). It represents the consensus of the IETF community. It has | |||
working documents as Internet-Drafts. The list of current Internet- | received public review and has been approved for publication by the | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 5741. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | Information about the current status of this document, any errata, | |||
and may be updated, replaced, or obsoleted by other documents at any | and how to provide feedback on it may be obtained at | |||
time. It is inappropriate to use Internet-Drafts as reference | http://www.rfc-editor.org/info/rfc6660. | |||
material or to cite them other than as "work in progress." | ||||
This Internet-Draft will expire on October 19, 2012. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
1.2. Changes in This Version (to be removed by RFC Editor) . . 5 | 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4 | |||
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 8 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 | 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 5 | |||
2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 9 | 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 6 | |||
3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 9 | 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 7 | |||
4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 10 | 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 10 | 4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 7 | |||
4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 11 | 4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 8 | |||
4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 12 | ||||
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 12 | 5.1. PCN-Ingress-Node Behaviour . . . . . . . . . . . . . . . . 8 | |||
5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 15 | 5.2. PCN-Interior-Node Behaviour . . . . . . . . . . . . . . . 11 | |||
5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 15 | 5.2.1. Behaviour Common to All PCN-Interior-Nodes . . . . . . 11 | |||
5.2.2. Behaviour of PCN-interior Nodes Using Two | 5.2.2. Behaviour of PCN-Interior-Nodes Using Two | |||
PCN-markings . . . . . . . . . . . . . . . . . . . . . 15 | PCN-Markings . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.2.3. Behaviour of PCN-interior Nodes Using One | 5.2.3. Behaviour of PCN-Interior-Nodes Using One | |||
PCN-marking . . . . . . . . . . . . . . . . . . . . . 16 | PCN-Marking . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 17 | 5.3. PCN-Egress-Node Behaviour . . . . . . . . . . . . . . . . 13 | |||
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 17 | 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13 | |||
6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 17 | 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13 | |||
6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 18 | 6.2. Backward Compatibility with the Encoding in RFC 5696 . . . 14 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 19 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 | Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 18 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 20 | Appendix B. Coexistence of ECN and PCN . . . . . . . . . . . . . 19 | |||
Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 22 | ||||
Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 23 | ||||
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 . . . . . . . . . . . . . 26 | IP and in MPLS Shim Headers . . . . . . . . . . . . . 22 | |||
Appendix D. Rationale for Difference Between the Schemes | Appendix D. Rationale for Difference between the Schemes | |||
using One PCN-Marking . . . . . . . . . . . . . . . . 27 | Using One PCN-Marking . . . . . . . . . . . . . . . . 23 | |||
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 | |||
generally configured with different reference rates. Threshold- | generally configured with different reference rates. Threshold- | |||
marking marks all PCN packets once their traffic rate on a link | marking marks all PCN packets once their traffic rate on a link | |||
exceeds the configured reference rate (PCN-threshold-rate). Excess- | exceeds the configured reference rate (PCN-threshold-rate). Excess- | |||
traffic-marking marks only those PCN packets that exceed the | traffic-marking marks only those PCN packets that exceed the | |||
configured reference rate (PCN-excess-rate). The PCN-excess-rate is | configured reference rate (PCN-excess-rate). The PCN-excess-rate is | |||
typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes | typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes | |||
monitor the PCN-marks of received PCN-packets and pass information | monitor the PCN-marks of received PCN-packets and pass information | |||
about these PCN-marks to decision points which then decide whether to | about these PCN-marks to Decision Points that then decide whether to | |||
admit new flows or terminate existing flows | admit new flows or terminate existing flows [RFC6661] [RFC6662]. | |||
[I-D.ietf-pcn-cl-edge-behaviour], [I-D.ietf-pcn-sm-edge-behaviour]. | ||||
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 [RFC6662]. However, PCN-domains utilising the controlled | |||
utilising the controlled load edge behaviour | load edge behaviour [RFC6661] require three PCN marking states. This | |||
[I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states. | document extends the encoding that originally appeared in RFC 5696 by | |||
This document extends the RFC5696 encoding by redefining the | redefining the experimental codepoint as a third PCN marking state in | |||
experimental codepoint as a third PCN marking state in the IP header, | the IP header, but still using a single Diffserv codepoint. This | |||
but still using a single Diffserv codepoint. This encoding scheme is | encoding scheme is therefore called the "3-in-1 PCN encoding". It | |||
therefore called the "3-in-1 PCN encoding". It obsoletes the | obsoletes the [RFC5696] encoding, which provides only a subset of the | |||
[RFC5696] encoding, which provides only a sub-set of the same | same capabilities. | |||
capabilities. | ||||
The full version of the 3-in-1 encoding requires any tunnel endpoint | The full version of the 3-in-1 encoding requires any tunnel endpoint | |||
within the PCN-domain to support the normal tunnelling rules defined | within the PCN-domain to support the normal tunnelling rules defined | |||
in [RFC6040]. There is one limited exception to this constraint | in [RFC6040]. There is one limited exception to this constraint | |||
where the PCN-domain only uses the excess-traffic-marking behaviour | where the PCN-domain only uses the excess-traffic-marking behaviour | |||
and 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 | |||
skipping to change at page 5, line 18 | skipping to change at page 4, line 21 | |||
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) | ||||
From draft-ietf-pcn-3-in-1-encoding-10 to -11: | ||||
* Pointed out that any DSCP re-mapping must precede PCN-ingress | ||||
processing; | ||||
* Ingress behaviour for ECN-capable PCN-packets: allowed any PCN- | ||||
capable encapsulation, not just IP-in-IP tunnelling. Added | ||||
cautionary note about MPLS PHP; | ||||
* PCN-policing at ingress: | ||||
+ Clarified what per-flow policing entails; | ||||
+ Clarified that a DSCP of zero is '000000'; | ||||
+ For policed packets, added SHOULD log, MAY alarm; | ||||
* Updated refs and acks. | ||||
From draft-ietf-pcn-3-in-1-encoding-09 to -10: | ||||
* Added cautionary management advice to S6.2 (backwards | ||||
compatibility with RFC5696) | ||||
* Removed "emphatically" from normative "NOT RECOMMENDED" text. | ||||
* Minor editoral changes. | ||||
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 | ||||
and clarifications. | ||||
From draft-ietf-pcn-3-in-1-encoding-06 to -07: | ||||
* Clarified that each operator not the IETF chooses which DSCP(s) | ||||
are PCN-compatible, and made it unambiguous that only PCN-nodes | ||||
recognise that PCN-compatible DSCPs enable the 3-in-1 encoding. | ||||
* Removed statements about the PCN working group, given RFCs are | ||||
meant to survive beyond the life of a w-g. | ||||
* Corrected the final para of "Rationale for Different Behaviours | ||||
in Schemes with Only One Marking" | ||||
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 only one PCN- | ||||
Marking. Added an appendix explaining an apparent | ||||
inconsistency within this section. | ||||
* 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: | ||||
* Draft moved to standards track as per working group | ||||
discussions. | ||||
* Added Appendix B discussing ECN handling in the PCN-domain. | ||||
* Clarified that this document modifies [RFC5696]. | ||||
From draft-ietf-pcn-3-in-1-encoding-03 to -04: | ||||
* Updated document to reflect RFC6040. | ||||
* Re-wrote introduction. | ||||
* Re-wrote section on applicability. | ||||
* Re-wrote section on choosing encoding scheme. | ||||
* Updated author details. | ||||
From draft-ietf-pcn-3-in-1-encoding-02 to -03: | ||||
* Corrected mistakes in introduction and improved overall | ||||
readability. | ||||
* Added new terminology. | ||||
* Rewrote a good part of Section 4 and 5 to achieve more clarity. | ||||
* Added appendix explaining when to use which encoding scheme and | ||||
how to encode them in MPLS shim headers. | ||||
* Added new co-author. | ||||
From draft-ietf-pcn-3-in-1-encoding-01 to -02: | ||||
* Corrected mistake in introduction, which wrongly stated that | ||||
the threshold-traffic rate is higher than the excess-traffic | ||||
rate. Other minor corrections. | ||||
* Updated acks & refs. | ||||
From draft-ietf-pcn-3-in-1-encoding-00 to -01: | ||||
* Altered the wording to make sense if | ||||
draft-ietf-tsvwg-ecn-tunnel moves to proposed standard. | ||||
* References updated | ||||
From draft-briscoe-pcn-3-in-1-encoding-00 to | ||||
draft-ietf-pcn-3-in-1-encoding-00: | ||||
* Filename changed to draft-ietf-pcn-3-in-1-encoding. | ||||
* Introduction altered to include new template description of | ||||
PCN. | ||||
* References updated. | ||||
* Terminology brought into line with [RFC5670]. | ||||
* Minor corrections. | ||||
2. Definitions and Abbreviations | 2. Definitions and Abbreviations | |||
2.1. Terminology | 2.1. Terminology | |||
The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node, | The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node, | |||
PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and PCN- | PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets, and | |||
marking are used as defined in [RFC5559]. The following additional | PCN-marking are used as defined in [RFC5559]. The following | |||
terms are defined in this document: | additional 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. | |||
PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating | PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating | |||
packets for which the ECN field carries PCN-markings rather than | packets for which the ECN field carries PCN-markings rather than | |||
[RFC3168] markings. Note that an operator configures PCN-nodes to | [RFC3168] markings. Note that an operator configures PCN-nodes to | |||
recognise PCN-compatible DSCPs, whereas the same DSCP has no PCN- | recognise PCN-compatible DSCPs, whereas the same DSCP has no PCN- | |||
specific meaning to a node outside the PCN domain. | specific meaning to a node outside the PCN-domain. | |||
Threshold-marked codepoint: a codepoint that indicates a packet has | Threshold-marked codepoint: a codepoint that indicates a packet has | |||
been threshold-marked; that is a packet that has been marked at a | been threshold-marked; that is, a packet that has been marked at a | |||
PCN-interior-node as a result of an indication from the threshold- | PCN-interior-node as a result of an indication from the threshold- | |||
metering function [RFC5670]. Abbreviated to ThM. | metering function [RFC5670]. Abbreviated to ThM codepoint. | |||
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 codepoint. | |||
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 codepoint. | |||
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] | |||
skipping to change at page 9, line 28 | skipping to change at page 5, line 28 | |||
o DSCP = Diffserv codepoint | o DSCP = Diffserv codepoint | |||
o e2e = end-to-end | 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 NM = Not-marked | o NM = not-marked | |||
o PCN = Pre-Congestion Notification | o PCN = Pre-Congestion Notification | |||
o PHB = Per-hop behaviour [RFC2474] | o PHB = Per-hop behaviour [RFC2474] | |||
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 supports networks that need three PCN- | The 3-in-1 PCN encoding scheme supports networks that need three PCN- | |||
marking states to be encoded within the IP header, as well as those | marking states to be encoded within the IP header, as well as those | |||
that need only two. The full encoding is 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 will be configured to recognise certain DSCPs as PCN- | A PCN-node will be configured to recognise certain DSCPs as PCN- | |||
compatible. Appendix A discusses the choice of suitable DSCPs. In | compatible. Appendix A discusses the choice of suitable DSCPs. In | |||
Figure 1 'DSCP n' indicates such a PCN-compatible DSCP. In the PCN- | Figure 1, 'DSCP n' indicates such a PCN-compatible DSCP. In the PCN- | |||
domain, any packet carrying a PCN-compatible DSCP and with the ECN- | domain, any packet carrying a PCN-compatible DSCP and with the ECN- | |||
field anything other than 00 (Not-PCN) is a PCN-packet as defined in | field anything other than 00 (not-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: | |||
Not-PCN: indicates a non-PCN-packet, i.e., a packet that uses a PCN- | not-PCN: indicates a non-PCN-packet, i.e., a packet that uses a PCN- | |||
compatible DSCP but is not subject to PCN metering and marking. | compatible DSCP but is not subject to PCN metering and marking. | |||
NM: Not-marked. Indicates a PCN-packet that has not yet been marked | NM: not-marked. Indicates a PCN-packet that has not yet been marked | |||
by any PCN marker. | by any PCN marker. | |||
ThM: Threshold-marked. Indicates a PCN-packet that has been marked | ThM: threshold-marked. Indicates a PCN-packet that has been marked | |||
by a threshold-marker [RFC5670]. | by a threshold-marker [RFC5670]. | |||
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 PCN-marking, and | |||
ingress-nodes mark them as Not-marked (PCN-colouring). All nodes in | PCN-ingress-nodes mark them as not-marked (PCN-colouring). All nodes | |||
the PCN-domain perform PCN-metering and PCN-mark PCN-packets if | in the PCN-domain perform PCN-metering and PCN-mark PCN-packets if | |||
needed. There are two different metering and marking behaviours: | needed. There are two different metering and marking behaviours: | |||
threshold-marking and excess-traffic-marking [RFC5670]. Some edge | threshold-marking and excess-traffic-marking [RFC5670]. Some edge | |||
behaviours require only a single marking behaviour | behaviours require only a Single Marking behaviour [RFC6662], others | |||
[I-D.ietf-pcn-sm-edge-behaviour], others require both | require both [RFC6661]. In the latter case, three PCN marking states | |||
[I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN | are needed: not-marked (NM) to indicate not-marked packets, | |||
marking states are needed: Not-marked (NM) to indicate not-marked | threshold-marked (ThM) to indicate packets marked by the threshold- | |||
packets, Threshold-marked (ThM) to indicate packets marked by the | marker, and excess-traffic-marked (ETM) to indicate packets marked by | |||
threshold-marker, and Excess-traffic-marked (ETM) to indicate packets | the excess-traffic-marker [RFC5670]. Threshold-marking and excess- | |||
marked by the excess-traffic-marker [RFC5670]. Threshold-marking and | traffic-marking are configured to start marking packets at different | |||
excess-traffic-marking are configured to start marking packets at | load conditions, so one marking behaviour indicates more severe pre- | |||
different load conditions, so one marking behaviour indicates more | congestion than the other. Therefore, a fourth PCN marking state | |||
severe pre-congestion than the other. Therefore, a fourth PCN | indicating that a packet is marked by both markers is not needed. | |||
marking state indicating that a packet is marked by both markers is | However, a fourth codepoint is required to indicate packets that use | |||
not needed. However a fourth codepoint is required to indicate | a PCN-compatible DSCP but do not use PCN-marking (the not-PCN | |||
packets that use a PCN-compatible DSCP but do not use PCN-marking | codepoint). | |||
(the Not-PCN codepoint). | ||||
In all current PCN edge behaviours 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] [RFC6661], excess-traffic-marking is configured with a | |||
is configured with a larger reference rate than threshold-marking. | larger reference rate than threshold-marking. We take this as a rule | |||
We take this as a rule and define excess-traffic-marked as a more | and define excess-traffic-marked as a more severe PCN-mark than | |||
severe PCN-mark than Threshold-marked. | 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 RFC 6040 | |||
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 [RFC6627]). | |||
[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. | |||
Even if an operator accidentally breaks these applicability rules, | Even if an operator accidentally breaks these applicability rules, | |||
the order of severity of the 3-in-1 codepoints was chosen to protect | 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 | other PCN or non-PCN traffic. Although legacy pre-RFC6040 tunnels | |||
did not propagate '01', all tunnels pre-RFC6040 and post-RFC6040 have | did not propagate '01', all tunnels pre-RFC6040 and post-RFC6040 have | |||
always propagated '11' correctly. Therefore '11' was chosen to | always propagated '11' correctly. Therefore, '11' was chosen to | |||
signal the most severe pre-congestion (ETM), so it would act as a | signal the most severe pre-congestion (ETM), so it would act as a | |||
reliable fail-safe even if an overlooked legacy tunnel was | reliable fail-safe even if an overlooked legacy tunnel was | |||
suppressing 01 (ThM) signals. | suppressing '01' (ThM) signals. | |||
4.3. Applicable Environments for the 3-in-1 PCN Encoding | 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 anywhere in 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). | |||
Operators may not be able to upgrade every pre-RFC6040 tunnel | Operators may not be able to upgrade every pre-RFC6040 tunnel | |||
endpoint within a PCN-domain. In such circumstances a limited | endpoint within a PCN-domain. In such circumstances, a limited | |||
version of the 3-in-1 encoding can still be used but only under the | version of the 3-in-1 encoding can still be used but only under the | |||
following stringent condition. If any pre-RFC6040 tunnel | following stringent condition. If any pre-RFC6040 tunnel | |||
decapsulator exists within a PCN-domain then every PCN-node in the | decapsulator exists within a PCN-domain, then every PCN-node in the | |||
PCN-domain MUST be configured so that it never sets the ThM | PCN-domain MUST be configured so that it never sets the ThM | |||
codepoint. PCN-interior-nodes in this case MUST solely use the | codepoint. PCN-interior-nodes in this case MUST solely use the | |||
Excess-traffic-marking function, as defined in Section 5.2.3.1. In | Excess-traffic-marking function, as defined in Section 5.2.3.1. In | |||
all other situations where legacy tunnel decapsulators might be | all other situations where legacy tunnel decapsulators might be | |||
present within the PCN domain, 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 | |||
If packets arrive from another Diffserv domain, any re-mapping of | If packets arrive from another Diffserv domain, any re-mapping of | |||
Diffserv codepoints MUST happen before PCN-ingress processing. | Diffserv codepoints MUST happen before PCN-ingress processing. | |||
At each logical ingress link into a PCN domain, each PCN-ingress node | At each logical ingress link into a PCN-domain, each PCN-ingress-node | |||
will apply the four functions described in Section 4.2 of [RFC5559] | will apply the four functions described in Section 4.2 of [RFC5559] | |||
to arriving packets. These functions are applied in the following | to arriving packets. These functions are applied in the following | |||
order: PCN-classify, PCN-police, PCN-colour, PCN-rate-meter. This | order: PCN-classify, PCN-police, PCN-colour, PCN-rate-meter. This | |||
section describes these four steps, but only the aspects relevant to | section describes these four steps, but only the aspects relevant to | |||
packet encoding: | packet encoding: | |||
1. PCN-classification: The PCN-ingress-node determines whether each | 1. PCN-classification: The PCN-ingress-node determines whether each | |||
packet matches the filter spec of an admitted flow. Packets that | packet matches the filter spec of an admitted flow. Packets that | |||
match are defined as PCN-packets. | match are defined as PCN-packets. | |||
1b. Extra step if ECN and PCN co-exist: If a packet classified as a | 1b. Extra step if ECN and PCN coexist: If a packet classified as a | |||
PCN-packet arrives with the ECN field already set to a value other | 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 | 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 | comply with BCP 124 [RFC4774] it MUST pass through one of the | |||
following preparatory steps before the PCN-policing and PCN- | following preparatory steps before the PCN-policing and PCN- | |||
colouring steps. The choice between these four actions depends on | colouring steps. The choice between these four actions depends on | |||
local policy: | local policy: | |||
* Encapsulate ECN-capable PCN-packets across the PCN-domain: | * Encapsulate ECN-capable PCN-packets across the PCN-domain: | |||
+ either within another IP header using an RFC6040 tunnel; | + either within another IP header using an RFC6040 tunnel; | |||
+ or within a lower layer protocol capable of being PCN | + or within a lower-layer protocol capable of being PCN- | |||
marked, such as MPLS (see Appendix C). | marked, such as MPLS (see Appendix C). | |||
Encapsulation using either of these methods is the RECOMMENDED | Encapsulation using either of these methods is the RECOMMENDED | |||
policy for ECN-capable PCN-packets, and implementations SHOULD | policy for ECN-capable PCN-packets, and implementations SHOULD | |||
use IP-in-IP tunnelling as the default. | use IP-in-IP tunnelling as the default. | |||
If encapsulation is used, it MUST precede PCN-policing and PCN- | If encapsulation is used, it MUST precede PCN-policing and PCN- | |||
colouring so that the encapsulator and decapsulator are | colouring so that the encapsulator and decapsulator are | |||
logically outside the PCN domain (see Appendix B and | logically outside the PCN-domain (see Appendix B and | |||
specifically Figure 2). | specifically Figure 2). | |||
If MPLS encapsulation is used, note that penultimate hop | If MPLS encapsulation is used, note that penultimate hop | |||
popping [RFC3031] is incompatible with PCN, unless the | popping [RFC3031] is incompatible with PCN, unless the | |||
penultimate hop applies the PCN-egress node behaviour before it | penultimate hop applies the PCN-egress-node behaviour before it | |||
pops the PCN-capable MPLS label. | pops the PCN-capable MPLS label. | |||
* If some form of encapsulation is not possible, the PCN-ingress- | * If some form of encapsulation is not possible, the PCN-ingress- | |||
node can allow through ECN-capable packets without | node can allow through ECN-capable packets without | |||
encapsulation, but it MUST drop CE-marked packets at this | encapsulation, but it MUST drop CE-marked packets at this | |||
stage. Failure to drop CE would risk congestion collapse, | stage. Failure to drop CE-marked packets would risk congestion | |||
because without encapsulation there is no mechanism to | collapse, because without encapsulation there is no mechanism | |||
propagate the CE markings across the PCN-domain (see | to propagate the CE markings across the PCN-domain (see | |||
Appendix B). | Appendix B). | |||
This policy is NOT RECOMMENDED because there is no tunnel to | This policy is NOT RECOMMENDED because there is no tunnel to | |||
protect the e2e ECN capability, which is otherwise disabled | protect the e2e ECN capability, which is otherwise disabled | |||
when the PCN-egress-node zeroes the ECN field. | when the PCN-egress-node zeroes the ECN field. | |||
* Drop the packet. | * Drop the packet. | |||
This policy is also NOT RECOMMENDED, because it precludes the | This policy is also NOT RECOMMENDED, because it precludes the | |||
possibility that e2e ECN can co-exist with PCN as a means of | possibility that e2e ECN can coexist with PCN as a means of | |||
controlling congestion. | controlling congestion. | |||
* Any other action that complies with [RFC4774] (see Appendix B | * Any other action that complies with [RFC4774] (see Appendix B | |||
for an example). | for an example). | |||
Appendix B provides more information about the co-existence of PCN | Appendix B provides more information about the coexistence of PCN | |||
and ECN. | and ECN. | |||
2. PCN-Policing: The PCN-policing function only allows appropriate | 2. PCN-policing: The PCN-policing function only allows appropriate | |||
packets into the PCN behaviour aggregate. Per-flow policing | packets into the PCN behaviour aggregate. Per-flow policing | |||
actions may be required to block rejected flows and to rate-police | actions may be required to block rejected flows and to rate-police | |||
accepted flows, but these are specified in the relevant edge- | accepted flows, but these are specified in the relevant edge- | |||
behaviour document, e.g. [I-D.ietf-pcn-sm-edge-behaviour], | behaviour document, e.g., [RFC6662] or [RFC6661]. | |||
[I-D.ietf-pcn-cl-edge-behaviour]. | ||||
Here we only specify packet-level PCN-policing, which prevents | Here, we only specify packet-level PCN-policing, which prevents | |||
packets that are not PCN-packets from being forwarded into the | packets that are not PCN-packets from being forwarded into the | |||
PCN-domain if PCN-interior-nodes would otherwise mistake them for | PCN-domain if PCN-interior-nodes would otherwise mistake them for | |||
PCN-packets. A non-PCN-packet will be confused with a PCN-packet | PCN-packets. A non-PCN-packet will be confused with a PCN-packet | |||
if on arrival it meets all three of the following conditions: | if on arrival it meets all three of the following conditions: | |||
a) it is not classified as a PCN-packet | a) it is not classified as a PCN-packet; | |||
b) it already carries a PCN-compatible DSCP | b) it already carries a PCN-compatible DSCP; and | |||
c) its ECN field carries a codepoint other than Not-ECT. | c) its ECN field carries a codepoint other than Not-ECT. | |||
The PCN-ingress-node MUST police packets that meet all three | The PCN-ingress-node MUST police packets that meet all three | |||
conditions (a-c) by subjecting them to one of the following | conditions (a-c) by subjecting them to one of the following | |||
treatments: | treatments: | |||
* re-mark the DSCP to a DSCP that is not PCN-compatible; | * 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 | * tunnel the packet to the PCN-egress-node with a DSCP in the | |||
header that is not PCN-compatible; | outer header that is not PCN-compatible; or | |||
* drop the packet (NOT RECOMMENDED--see below). | * drop the packet (NOT RECOMMENDED -- see below). | |||
The choice between these actions depends on local policy. In the | The choice between these actions depends on local policy. In the | |||
absence of any operator-specific configuration for this case, by | absence of any operator-specific configuration for this case, an | |||
default an implementation SHOULD re-mark the DSCP to zero | implementation SHOULD re-mark the DSCP to zero (000000) by | |||
(000000). | default. | |||
Whichever policing action is chosen, the PCN-ingress-node SHOULD | Whichever policing action is chosen, the PCN-ingress-node SHOULD | |||
log the event and MAY also raise an alarm. Alarms SHOULD be rate- | log the event and MAY also raise an alarm. Alarms SHOULD be rate- | |||
limited so that the anomalous packets will not amplify into a | limited so that the anomalous packets will not amplify into a | |||
flood of alarm messages. | flood of alarm messages. | |||
Rationale: Traffic that meets all three of the above conditions | Rationale: Traffic that meets all three of the above conditions | |||
(a-c) is not PCN-traffic, therefore ideally a PCN-ingress ought | (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 | not to interfere with it, but it has to do something to avoid | |||
ambiguous packet markings. Clearing the ECN field is not an | ambiguous packet markings. Clearing the ECN field is not an | |||
appropriate policing action, because a network node ought not to | appropriate policing action, because a network node ought not to | |||
interfere with an e2e signal. Even if such packets seem like an | interfere with an e2e signal. Even if such packets seem like an | |||
attack, drop would be overkill, because such an attack can be | attack, drop would be overkill, because such an attack can be | |||
neutralised by just re-marking the DSCP. And DSCP re-marking in | neutralised by just re-marking the DSCP. And DSCP re-marking in | |||
the network is legitimate, because the DSCP is not considered an | the network is legitimate, because the DSCP is not considered an | |||
e2e signal. | e2e signal. | |||
3. PCN-colouring: If a packet has been classified as a PCN-packet, | 3. PCN-colouring: If a packet has been classified as a PCN-packet, | |||
once it has been policed, the PCN-ingress-node: | once it has been policed, the PCN-ingress-node: | |||
* MUST set a PCN-compatible Diffserv codepoint on all PCN- | * MUST set a PCN-compatible Diffserv codepoint on all PCN- | |||
packets. To conserve DSCPs, Diffserv codepoints SHOULD be | packets. To conserve DSCPs, DSCPs SHOULD be chosen that are | |||
chosen that are already defined for use with admission- | already defined for use with admission-controlled traffic. | |||
controlled traffic. Appendix A gives guidance to implementors | Appendix A gives guidance to implementors on suitable DSCPs. | |||
on suitable DSCPs. | ||||
* MUST set the PCN codepoint of all PCN-packets to Not-marked | * MUST set the PCN codepoint of all PCN-packets to not-marked | |||
(NM). | (NM). | |||
4. PCN rate-metering: This fourth step may be necessary depending on | 4. PCN rate-metering: This fourth step may be necessary depending on | |||
the edge-behaviour in force. It is listed for completeness, but | the edge behaviour in force. It is listed for completeness, but | |||
it is not relevant to this encoding document. | 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 [RFC6662] requires PCN- | |||
[I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior-nodes to mark | interior-nodes to mark packets using the excess-traffic-meter | |||
packets using the excess-traffic-meter function [RFC5670]. It is | function [RFC5670]. It is possible that future schemes may require | |||
possible that future schemes may require only the threshold-meter | only the threshold-meter function. Appendix D explains the rationale | |||
function. Appendix D explains the rationale for the behaviours | 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; | |||
skipping to change at page 16, line 47 | skipping to change at page 13, line 4 | |||
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 ECN 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; if only threshold-marking | |||
marking is used, it SHOULD treat ETM as ThM. However it SHOULD raise | is used, it SHOULD treat ETM as ThM. However, it SHOULD raise a | |||
a management alarm in either case since this means there is some | 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 coexistence 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. | |||
There is not enough space in one IP header for the 3-in-1 encoding to | There is not enough space in one IP header for the 3-in-1 encoding to | |||
support both ECN marking end-to-end and PCN-marking within a PCN- | support both ECN marking end-to-end and PCN-marking within a PCN- | |||
domain. The non-normative Appendix B discusses possible ways to do | domain. The non-normative Appendix B discusses possible ways to do | |||
this, e.g. by carrying e2e ECN across a PCN-domain within the inner | this, e.g., by carrying e2e ECN across a PCN-domain within the inner | |||
header of an IP-in-IP tunnel. The normative text in Section 5.1 | header of an IP-in-IP tunnel. The normative text in Section 5.1 | |||
requires one of these methods to be configured at the PCN-ingress- | requires one of these methods to be configured at the PCN-ingress- | |||
node and recommends that implementations offer tunnelling as the | node and recommends that implementations offer tunnelling as the | |||
default. | 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 Encoding in RFC 5696 | |||
Section 5.1 of the PCN architecture gives general guidance on fault | Section 5.1 of the PCN architecture [RFC5559] gives general guidance | |||
detection and diagnosis [RFC5559], including management analysis of | on fault detection and diagnosis, including management analysis of | |||
PCN markings arriving at PCN-egress nodes to detect early signs of | PCN markings arriving at PCN-egress-nodes to detect early signs of | |||
potential faults. Because the PCN encoding has gone through an | potential faults. Because the PCN encoding has gone through an | |||
obsoleted earlier stage [RFC5696], misconfiguration mistakes may be | obsoleted earlier stage [RFC5696], misconfiguration mistakes may be | |||
more likely. Therefore extra monitoring, such as in the following | more likely. Therefore, extra monitoring, such as in the following | |||
example, may be necessary to detect and diagnose potential problems: | example, may be necessary to detect and diagnose potential problems: | |||
Informational example: In a controlled-load edge-behaviour | Informational example: In a controlled-load edge-behaviour | |||
scenario it could be worth the PCN-egress node detecting the onset | scenario it could be worth the PCN-egress-node detecting the onset | |||
of excess-traffic marking without any prior threshold-marking. | of excess-traffic marking without any prior threshold-marking. | |||
This might indicate that an interior node has been wrongly | This might indicate that an interior node has been wrongly | |||
configured to mark only ETM (which would have been correct for the | configured to mark only ETM (which would have been correct for the | |||
single-marking edge-behaviour). | single-marking edge behaviour). | |||
A PCN-node implemented to use the obsoleted RFC5696 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, there is no known deployment of this rather | ||||
unlikely variant of RFC5696 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 | ||||
This memo includes no request to IANA. | ||||
Note to RFC Editor: this section may be removed on publication as an | A PCN-node implemented to use the obsoleted encoding in RFC 5696 | |||
RFC. | 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, there is no known deployment of this | ||||
rather unlikely variant of RFC 5696 and no reason to believe that | ||||
such an implementation would ever have been built. Therefore, it | ||||
seems safe to ignore this issue. | ||||
8. Security Considerations | 7. Security Considerations | |||
PCN-marking only carries a meaning within the confines of a PCN- | PCN-marking only carries a meaning within the confines of a PCN- | |||
domain. This encoding document is intended to stand independently of | domain. This encoding document is intended to stand independently of | |||
the architecture used to determine how specific packets are | the architecture used to determine how specific packets are | |||
authorised to be PCN-marked, which will be described in separate | authorised to be PCN-marked, which will be described in separate | |||
documents on PCN-boundary-node behaviour. | documents on PCN-boundary-node behaviour. | |||
This document assumes the PCN-domain to be entirely under the control | This document assumes the PCN-domain to be entirely under the control | |||
of a single operator, or a set of operators who trust each other. | of a single operator, or a set of operators who trust each other. | |||
However, future extensions to PCN might include inter-domain versions | However, future extensions to PCN might include inter-domain versions | |||
where trust cannot be assumed between domains. If such schemes are | where trust cannot be assumed between domains. If such schemes are | |||
proposed, they must ensure that they can operate securely despite the | proposed, they must ensure that they can operate securely despite the | |||
lack of trust. However, such considerations are beyond the scope of | lack of trust. However, such considerations are beyond the scope of | |||
this document. | this document. | |||
One potential security concern is the injection of spurious PCN-marks | One potential security concern is the injection of spurious PCN-marks | |||
into the PCN-domain. However, these can only enter the domain if a | into the PCN-domain. However, these can only enter the domain if a | |||
PCN-ingress-node is misconfigured. The precise impact of any such | PCN-ingress-node is misconfigured. The precise impact of any such | |||
misconfiguration will depend on which of the proposed PCN-boundary- | misconfiguration will depend on which of the proposed PCN-boundary- | |||
node behaviours is used, but in general spurious marks will lead to | node behaviours is used; however, in general, spurious marks will | |||
admitting fewer flows into the domain or potentially terminating too | lead to admitting fewer flows into the domain or potentially | |||
many flows. In either case, good management should be able to | terminating too many flows. In either case, good management should | |||
quickly spot the problem since the overall utilisation of the domain | be able to quickly spot the problem since the overall utilisation of | |||
will rapidly fall. | the domain will rapidly fall. | |||
9. Conclusions | 8. 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. | |||
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 | 9. Acknowledgements | |||
Many thanks to Philip 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 Karagiannis, James Polk, Tom Taylor, Adrian | Ruediger Geib, Georgios Karagiannis, James Polk, Tom Taylor, Adrian | |||
Farrel and everyone else who has commented on the document. | Farrel, and everyone else who has commented on the document. | |||
11. Comments Solicited | ||||
To be removed by RFC Editor: Comments and questions are encouraged | ||||
and very welcome. They can be addressed to the IETF Congestion and | ||||
Pre-Congestion working group mailing list <pcn@ietf.org>, and/or to | ||||
the authors. | ||||
12. References | 10. References | |||
12.1. Normative References | 10.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
in RFCs to Indicate Requirement | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
Levels", BCP 14, RFC 2119, | ||||
March 1997. | ||||
[RFC2474] Nichols, K., Blake, S., Baker, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
F., and D. Black, "Definition of | "Definition of the Differentiated Services Field (DS | |||
the Differentiated Services Field | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
(DS Field) in the IPv4 and IPv6 | December 1998. | |||
Headers", RFC 2474, | ||||
December 1998. | ||||
[RFC3168] Ramakrishnan, K., Floyd, S., and | [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | |||
D. Black, "The Addition of | of Explicit Congestion Notification (ECN) to IP", | |||
Explicit Congestion Notification | RFC 3168, September 2001. | |||
(ECN) to IP", RFC 3168, | ||||
September 2001. | ||||
[RFC5559] Eardley, P., "Pre-Congestion | [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) | |||
Notification (PCN) Architecture", | Architecture", RFC 5559, June 2009. | |||
RFC 5559, June 2009. | ||||
[RFC5670] Eardley, P., "Metering and | [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- | |||
Marking Behaviour of PCN-Nodes", | Nodes", RFC 5670, November 2009. | |||
RFC 5670, November 2009. | ||||
[RFC6040] Briscoe, B., "Tunnelling of | [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion | |||
Explicit Congestion | Notification", RFC 6040, November 2010. | |||
Notification", RFC 6040, | ||||
November 2010. | ||||
12.2. Informative References | 10.2. Informative References | |||
[I-D.ietf-pcn-cl-edge-behaviour] Charny, A., Huang, F., | [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, | |||
Karagiannis, G., Menth, M., and | "Assured Forwarding PHB Group", RFC 2597, June 1999. | |||
T. Taylor, "PCN Boundary Node | ||||
Behaviour for the Controlled Load | ||||
(CL) Mode of Operation", draft- | ||||
ietf-pcn-cl-edge-behaviour-14 | ||||
(work in progress), April 2012. | ||||
[I-D.ietf-pcn-encoding-comparison] Karagiannis, G., Chan, K., | [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | |||
Moncaster, T., Menth, M., | Label Switching Architecture", RFC 3031, January 2001. | |||
Eardley, P., and B. Briscoe, | ||||
"Overview of Pre-Congestion | ||||
Notification Encoding", draft- | ||||
ietf-pcn-encoding-comparison-09 | ||||
(work in progress), March 2012. | ||||
[I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., | [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, | |||
Menth, M., and T. Taylor, "PCN | J., Courtney, W., Davari, S., Firoiu, V., and D. | |||
Boundary Node Behaviour for the | Stiliadis, "An Expedited Forwarding PHB (Per-Hop | |||
Single Marking (SM) Mode of | Behavior)", RFC 3246, March 2002. | |||
Operation", draft-ietf-pcn-sm- | ||||
edge-behaviour-12 (work in | ||||
progress), April 2012. | ||||
[RFC2597] Heinanen, J., Baker, F., Weiss, | [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit | |||
W., and J. Wroclawski, "Assured | Congestion Notification (ECN) Signaling with Nonces", | |||
Forwarding PHB Group", RFC 2597, | RFC 3540, June 2003. | |||
June 1999. | ||||
[RFC3031] Rosen, E., Viswanathan, A., and | [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration | |||
R. Callon, "Multiprotocol Label | Guidelines for DiffServ Service Classes", RFC 4594, | |||
Switching Architecture", | August 2006. | |||
RFC 3031, January 2001. | ||||
[RFC3246] Davie, B., Charny, A., Bennet, | [RFC4774] Floyd, S., "Specifying Alternate Semantics for the | |||
J., Benson, K., Le Boudec, J., | Explicit Congestion Notification (ECN) Field", BCP 124, | |||
Courtney, W., Davari, S., Firoiu, | RFC 4774, November 2006. | |||
V., and D. Stiliadis, "An | ||||
Expedited Forwarding PHB (Per-Hop | ||||
Behavior)", RFC 3246, March 2002. | ||||
[RFC3540] Spring, N., Wetherall, D., and D. | [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of | |||
Ely, "Robust Explicit Congestion | Diffserv Service Classes", RFC 5127, February 2008. | |||
Notification (ECN) Signaling with | ||||
Nonces", RFC 3540, June 2003. | ||||
[RFC4594] Babiarz, J., Chan, K., and F. | [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion | |||
Baker, "Configuration Guidelines | Marking in MPLS", RFC 5129, January 2008. | |||
for DiffServ Service Classes", | ||||
RFC 4594, August 2006. | ||||
[RFC4774] Floyd, S., "Specifying Alternate | [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching | |||
Semantics for the Explicit | (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic | |||
Congestion Notification (ECN) | Class" Field", RFC 5462, February 2009. | |||
Field", BCP 124, RFC 4774, | ||||
November 2006. | ||||
[RFC5127] Chan, K., Babiarz, J., and F. | [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline | |||
Baker, "Aggregation of DiffServ | Encoding and Transport of Pre-Congestion Information", | |||
Service Classes", RFC 5127, | RFC 5696, November 2009. | |||
February 2008. | ||||
[RFC5129] Davie, B., Briscoe, B., and J. | [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated | |||
Tay, "Explicit Congestion Marking | Services Code Point (DSCP) for Capacity-Admitted Traffic", | |||
in MPLS", RFC 5129, January 2008. | RFC 5865, May 2010. | |||
[RFC5462] Andersson, L. and R. Asati, | [RFC6627] Karagiannis, G., Chan, K., Moncaster, T., Menth, M., | |||
"Multiprotocol Label Switching | Eardley, P., and B. Briscoe, "Overview of Pre-Congestion | |||
(MPLS) Label Stack Entry: "EXP" | Notification Encoding", RFC 6627, July 2012. | |||
Field Renamed to "Traffic Class" | ||||
Field", RFC 5462, February 2009. | ||||
[RFC5696] Moncaster, T., Briscoe, B., and | [RFC6661] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. | |||
M. Menth, "Baseline Encoding and | Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary- | |||
Transport of Pre-Congestion | Node Behaviour for the Controlled Load (CL) Mode of | |||
Information", RFC 5696, | Operation", RFC 6661, July 2012. | |||
November 2009. | ||||
[RFC5865] Baker, F., Polk, J., and M. | [RFC6662] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. | |||
Dolly, "A Differentiated Services | Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary- | |||
Code Point (DSCP) for Capacity- | Node Behaviour for the Single Marking (SM) Mode of | |||
Admitted Traffic", RFC 5865, | Operation", RFC 6662, July 2012. | |||
May 2010. | ||||
Appendix A. Choice of Suitable DSCPs | Appendix A. Choice of Suitable DSCPs | |||
This appendix is informative, not normative. | This appendix is informative not normative. | |||
A single DSCP has not been defined for use with PCN for several | A single DSCP has not been defined for use with PCN for several | |||
reasons. Firstly, the PCN mechanism is applicable to a variety of | reasons. Firstly, the PCN mechanism is applicable to a variety of | |||
different traffic classes. Secondly, Standards Track DSCPs are in | different traffic classes. Secondly, Standards Track DSCPs are in | |||
increasingly short supply. Thirdly, PCN is not a scheduling | increasingly short supply. Thirdly, PCN is not a scheduling | |||
behaviour -- rather, it should be seen as being a marking behaviour | behaviour -- rather, it should be seen as being a marking behaviour | |||
similar to ECN but intended for inelastic traffic. The choice of | similar to ECN but intended for inelastic traffic. The choice of | |||
which DSCP is most suitable for a given PCN-domain is dependent on | 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 | 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 | all the links making up that domain. In PCN-domains with sufficient | |||
skipping to change at page 23, line 25 | skipping to change at page 19, line 16 | |||
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. Coexistence of ECN and PCN | |||
This appendix is informative, not normative. It collects together | This appendix is informative not normative. It collects together | |||
material relevant to co-existence of ECN and PCN, including that | material relevant to coexistence of ECN and PCN, including that | |||
spread throughout the body of this specification. If this results in | spread throughout the body of this specification. If this results in | |||
any conflict or ambiguity, the normative text in the body of the | any conflict or ambiguity, the normative text in the body of the | |||
specification takes precedence. | specification takes precedence. | |||
ECN [RFC3168] is an e2e congestion notification mechanism. As such | ECN [RFC3168] is an e2e congestion notification mechanism. As such | |||
it is possible that some traffic entering the PCN-domain may also be | it is possible that some traffic entering the PCN-domain may also be | |||
ECN-capable. The PCN encoding described in this document re-uses the | ECN-capable. The PCN encoding described in this document reuses the | |||
bits of the ECN field in the IP header. Consequently, this disables | bits of the ECN field in the IP header. Consequently, this disables | |||
ECN within the PCN domain. | 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 | |||
might arrive at a PCN-ingress-node. These are admission-controlled | that might arrive at a PCN-ingress-node. These are admission- | |||
traffic (PCN-traffic) and non-admission-controlled traffic (non-PCN- | controlled traffic (PCN-traffic) and non-admission-controlled traffic | |||
traffic). | (non-PCN-traffic). | |||
Flow signalling identifies admission controlled traffic, by | Flow signalling identifies admission-controlled traffic, by | |||
associating a filterspec with the need for admission control (e.g. | associating a filter spec with the need for admission control (e.g., | |||
through RSVP or some equivalent message, e.g. from a SIP server to | through RSVP or some equivalent message, such as from a SIP server to | |||
the ingress or from a logically centralised network control system). | the ingress or from a logically centralised network control system). | |||
The PCN-ingress-node re-marks admission-conrolled traffic matching | The PCN-ingress-node re-marks admission-controlled traffic matching | |||
that filterspec to a PCN-compatible DSCP. Note that the term flow | that filter spec to a PCN-compatible DSCP. Note that the term "flow" | |||
need not imply just one microflow, but instead could match an | need not imply just one microflow, but instead could match an | |||
aggregate and/or could depend on the incoming DSCP (see Appendix A). | 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. | |||
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 that complies with[RFC6040] can be used to | an IP-in-IP tunnel that complies with [RFC6040] can be used to | |||
preserve ECN markings across the PCN domain. The tunnelling action | preserve ECN markings across the PCN-domain. The tunnelling action | |||
should be applied wholly outside the PCN-domain as illustrated in | should be applied wholly outside the PCN-domain as illustrated in | |||
Figure 2. Then, by the rules of RFC6040, the tunnel egress | Figure 2. Then, by the rules of RFC 6040, the tunnel egress | |||
propagates the ECN field from the inner header, because the PCN- | propagates the ECN field from the inner header, because the PCN- | |||
egress will have zeroed the outer ECN field. | 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 PCN 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 signalling being | |||
for admission control. In this case the e2e ECN traffic is not | used for admission control. In this case, the e2e ECN traffic is | |||
treated as PCN-traffic. There are two possible scenarios: | not 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 the DSCP in the | 2. The ingress tunnels the traffic, setting the DSCP in the | |||
outer header to a local DSCP with the same scheduling PHB | outer header to a local DSCP with the same scheduling PHB | |||
as the original DSCP. | as the original DSCP. | |||
3. The ingress tunnels the traffic, using the original DSCP in | 3. The ingress tunnels the traffic, using the original DSCP in | |||
the outer but setting Not-PCN in the outer header; note | the outer header but setting not-PCN in the outer header; | |||
that this turns off ECN for this traffic within the PCN | note that this turns off ECN for this traffic within the | |||
domain. | PCN-domain. | |||
The first or second options are recommended unless the operator | The first or second options are recommended unless the operator | |||
is short of local DSCPs. | 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 | |||
the ECN-field to NM and sets the DCSP to a PCN-compatible DSCP. | the ECN-field to NM and sets the DSCP 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 PCN admission control where the endpoints | c) Traffic that requires PCN admission control where the endpoints | |||
ask to 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- | |||
does not zero the ECN field contrary to the recommendation in | egress does not zero the ECN field (contrary to the recommendation | |||
Section 5.3, so that the [RFC6040] tunnel egress will preserve any | in Section 5.3), so that the [RFC6040] tunnel egress will preserve | |||
PCN-marking. Note that a PCN-interior-node may change the ECN- | any PCN-marking. Note that a PCN-interior-node may change the | |||
field from 10 to 01 (NM to ThM), which would be interpreted by the | ECN-field from '10' to '01' (NM to ThM), which would be | |||
e2e ECN as a change from ECT(0) into ECT(1). This would not be | interpreted by the e2e ECN as a change from ECT(0) into ECT(1). | |||
compatible with the (currently experimental) ECN nonce [RFC3540]. | This would not be 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 | |||
codepoints. When encapsulating IP traffic in MPLS, it is useful to | codepoints. When encapsulating IP traffic in MPLS, it is useful to | |||
make the DS field information accessible in the MPLS header. | make the DS field information accessible in the MPLS header. | |||
However, the MPLS shim header has only a 3-bit traffic class (TC) | However, the MPLS shim header has only a 3-bit traffic class (TC) | |||
skipping to change at page 26, line 28 | skipping to change at page 22, line 28 | |||
[RFC5129] describes how ECN markings in the IP header can also be | [RFC5129] describes how ECN markings in the IP header can also be | |||
mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129] | mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129] | |||
gives an informative description of how to support PCN in MPLS by | gives an informative description of how to support PCN in MPLS by | |||
extending the way MPLS supports ECN. [RFC5129] was written while PCN | extending the way MPLS supports ECN. [RFC5129] was written while PCN | |||
specifications were in early draft stages. The following provides a | specifications were in early draft stages. The following provides a | |||
clearer example of a mapping between PCN in IP and in MPLS using the | clearer example of a mapping between PCN in IP and in MPLS using the | |||
PCN terminology and concepts that have since been specified. | PCN terminology and concepts that have since been specified. | |||
To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n') | To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n') | |||
needs codepoints to be provided in the TC field for all the PCN-marks | needs codepoints to be provided in the TC field for all the PCN-marks | |||
used. That means, when for instance only excess-traffic-marking is | used. That means, when, for instance, only excess-traffic-marking is | |||
used for PCN purposes, the operator needs to define a site-local | used for PCN purposes, the operator needs to define a site-local | |||
mapping to two codepoints in the MPLS TC field for IP headers with: | mapping to two codepoints in the MPLS TC field for IP headers with: | |||
o DSCP n and NM | o DSCP n and NM | |||
o DSCP n and ETM | o DSCP n and ETM | |||
If both excess-traffic-marking and threshold-marking are used, the | If both excess-traffic-marking and threshold-marking are used, the | |||
operator needs to define a site-local mapping to codepoints in 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: | MPLS TC field for IP headers with all three of the 3-in-1 codepoints: | |||
skipping to change at page 26, line 51 | skipping to change at page 22, line 51 | |||
o DSCP n and ThM | o DSCP n and ThM | |||
o DSCP n and ETM | o DSCP n and ETM | |||
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- | Guidelines for conserving TC codepoints by allowing non-admission- | |||
controlled-traffic to compete with PCN-traffic are given in Appendix | controlled-traffic to compete with PCN-traffic are given in Appendix | |||
B.1 of [RFC5670]. | 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 | |||
Marking | PCN-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- | Sections 5.2.3.1 and 5.2.3.2. With only Excess-traffic-marking | |||
marking enabled, an unexpected ThM packet can be re-marked to ETM. | enabled, an unexpected ThM packet can be re-marked to ETM. However, | |||
However, with only Threshold-marking, an unexpected ETM packet cannot | with only Threshold-marking, an unexpected ETM packet cannot be re- | |||
be re-marked to ThM. | 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 | |||
skipping to change at page 28, line 4 | skipping to change at page 24, line 17 | |||
Bob Briscoe | Bob Briscoe | |||
BT | BT | |||
B54/77, Adastral Park | B54/77, Adastral Park | |||
Martlesham Heath | Martlesham Heath | |||
Ipswich IP5 3RE | Ipswich IP5 3RE | |||
UK | UK | |||
Phone: +44 1473 645196 | Phone: +44 1473 645196 | |||
EMail: bob.briscoe@bt.com | EMail: bob.briscoe@bt.com | |||
URI: http://bobbriscoe.net/ | URI: http://bobbriscoe.net/ | |||
Toby Moncaster | Toby Moncaster | |||
Moncaster Internet Consulting | University of Cambridge Computer Laboratory | |||
Dukes | William Gates Building, J J Thomson Avenue | |||
Layer Marney | Cambridge CB3 0FD | |||
Colchester CO5 9UZ | ||||
UK | UK | |||
Phone: +44 7764 185416 | EMail: toby.moncaster@cl.cam.ac.uk | |||
EMail: toby@moncaster.com | ||||
URI: http://www.moncaster.com/ | ||||
Michael Menth | Michael Menth | |||
University of Tuebingen | University of Tuebingen | |||
Sand 13 | Sand 13 | |||
Tuebingen 72076 | 72076 Tuebingen | |||
Germany | Germany | |||
Phone: +49 7071 2970505 | Phone: +49-7071-2970505 | |||
EMail: menth@informatik.uni-tuebingen.de | EMail: menth@uni-tuebingen.de | |||
End of changes. 155 change blocks. | ||||
535 lines changed or deleted | 327 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/ |