draft-ietf-pcn-3-in-1-encoding-09.txt | draft-ietf-pcn-3-in-1-encoding-10.txt | |||
---|---|---|---|---|
Congestion and Pre-Congestion B. Briscoe | Congestion and Pre-Congestion B. Briscoe | |||
Notification BT | Notification BT | |||
Internet-Draft T. Moncaster | Internet-Draft T. Moncaster | |||
Obsoletes: 5696 (if approved) Moncaster Internet Consulting | Obsoletes: 5696 (if approved) Moncaster Internet Consulting | |||
Intended status: Standards Track M. Menth | Intended status: Standards Track M. Menth | |||
Expires: September 12, 2012 University of Tuebingen | Expires: September 21, 2012 University of Tuebingen | |||
March 11, 2012 | March 20, 2012 | |||
Encoding 3 PCN-States in the IP header using a single DSCP | Encoding 3 PCN-States in the IP header using a single DSCP | |||
draft-ietf-pcn-3-in-1-encoding-09 | draft-ietf-pcn-3-in-1-encoding-10 | |||
Abstract | Abstract | |||
The objective of Pre-Congestion Notification (PCN) is to protect the | The objective of Pre-Congestion Notification (PCN) is to protect the | |||
quality of service (QoS) of inelastic flows within a Diffserv domain. | quality of service (QoS) of inelastic flows within a Diffserv domain. | |||
The overall rate of the PCN-traffic is metered on every link in the | The overall rate of the PCN-traffic is metered on every link in the | |||
PCN domain, and PCN-packets are appropriately marked when certain | PCN domain, and PCN-packets are appropriately marked when certain | |||
configured rates are exceeded. Egress nodes pass information about | configured rates are exceeded. Egress nodes pass information about | |||
these PCN-marks to decision points which then decide whether to admit | these PCN-marks to decision points which then decide whether to admit | |||
or block new flow requests or to terminate some already-admitted | or block new flow requests or to terminate some already-admitted | |||
skipping to change at page 2, line 4 | skipping to change at page 2, line 4 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 12, 2012. | This Internet-Draft will expire on September 21, 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 | |||
skipping to change at page 3, line 10 | skipping to change at page 3, line 10 | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | |||
1.2. Changes in This Version (to be removed by RFC Editor) . . 5 | 1.2. Changes in This Version (to be removed by RFC Editor) . . 5 | |||
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 7 | 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 8 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 8 | 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 8 | |||
3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 9 | 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 9 | |||
4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 10 | 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 10 | |||
4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 10 | 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 10 | |||
4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 10 | 4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 11 | |||
4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 11 | 4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 11 | |||
5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN | 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN | |||
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 11 | 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 12 | |||
5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 14 | 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 14 | |||
5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 14 | 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 14 | |||
5.2.2. Behaviour of PCN-interior Nodes Using Two | 5.2.2. Behaviour of PCN-interior Nodes Using Two | |||
PCN-markings . . . . . . . . . . . . . . . . . . . . . 14 | PCN-markings . . . . . . . . . . . . . . . . . . . . . 14 | |||
5.2.3. Behaviour of PCN-interior Nodes Using One | 5.2.3. Behaviour of PCN-interior Nodes Using One | |||
PCN-marking . . . . . . . . . . . . . . . . . . . . . 14 | PCN-marking . . . . . . . . . . . . . . . . . . . . . 15 | |||
5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 15 | 5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 15 | |||
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16 | 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16 | |||
6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 16 | 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 16 | |||
6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 16 | 6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 16 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 17 | 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 18 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 18 | 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 | |||
Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 20 | Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 21 | |||
Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 21 | Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 22 | |||
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 . . . . . . . . . . . . . 24 | IP and in MPLS Shim Headers . . . . . . . . . . . . . 24 | |||
Appendix D. Rationale for Difference Between the Schemes | Appendix D. Rationale for Difference Between the Schemes | |||
using One PCN-Marking . . . . . . . . . . . . . . . . 25 | using One PCN-Marking . . . . . . . . . . . . . . . . 25 | |||
1. Introduction | 1. Introduction | |||
The objective of Pre-Congestion Notification (PCN) [RFC5559] is to | The objective of Pre-Congestion Notification (PCN) [RFC5559] is to | |||
protect the quality of service (QoS) of inelastic flows within a | protect the quality of service (QoS) of inelastic flows within a | |||
Diffserv domain, in a simple, scalable, and robust fashion. Two | Diffserv domain, in a simple, scalable, and robust fashion. Two | |||
skipping to change at page 5, line 20 | skipping to change at page 5, line 20 | |||
mapping between IP and MPLS. | mapping between IP and MPLS. | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
1.2. Changes in This Version (to be removed by RFC Editor) | 1.2. Changes in This Version (to be removed by RFC Editor) | |||
From draft-ietf-pcn-3-in-1-encoding-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: | From draft-ietf-pcn-3-in-1-encoding-08 to -09: | |||
* Added note about fail-safe to protect other traffic in the | * Added note about fail-safe to protect other traffic in the | |||
event of tunnel misconfiguration. | event of tunnel misconfiguration. | |||
* Changed section heading to be about applicability of | * Changed section heading to be about applicability of | |||
environments to the encoding, rather than the encoding to the | environments to the encoding, rather than the encoding to the | |||
environments. | environments. | |||
* Completely re-wrote PCN-ingress Node Behaviour section. | * Completely re-wrote PCN-ingress Node Behaviour section. | |||
skipping to change at page 9, line 4 | skipping to change at page 9, line 15 | |||
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 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 | | |||
skipping to change at page 12, line 33 | skipping to change at page 12, line 46 | |||
This tunnelling policy is the RECOMMENDED choice, and | This tunnelling policy is the RECOMMENDED choice, and | |||
implementations SHOULD use it as the default. | implementations SHOULD use it as the default. | |||
* If tunnelling is not possible, the PCN-ingress-node can allow | * If tunnelling is not possible, the PCN-ingress-node can allow | |||
through ECN-capable packets without tunnelling, but it MUST | through ECN-capable packets without tunnelling, but it MUST | |||
drop CE-marked packets at this stage. Failure to drop CE would | drop CE-marked packets at this stage. Failure to drop CE would | |||
risk congestion collapse, because without a tunnel there is no | risk congestion collapse, because without a tunnel there is no | |||
mechanism to propagate the CE markings across the PCN-domain | mechanism to propagate the CE markings across the PCN-domain | |||
(see Appendix B). | (see Appendix B). | |||
This policy is emphatically NOT RECOMMENDED because there is no | This policy is NOT RECOMMENDED because there is no tunnel to | |||
tunnel to protect the e2e ECN capability, which is otherwise | protect the e2e ECN capability, which is otherwise disabled | |||
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 emphatically NOT RECOMMENDED, because it | This policy is also NOT RECOMMENDED, because it precludes the | |||
precludes the possibility that e2e ECN can co-exist with PCN as | possibility that e2e ECN can co-exist with PCN as a means of | |||
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 co-existence 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, but these are specified in the relevant | actions may be required, but these are specified in the relevant | |||
skipping to change at page 16, line 39 | skipping to change at page 16, line 49 | |||
PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress- | PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress- | |||
nodes ensure that any packets entering the PCN-domain have the ECN | nodes ensure that any packets entering the PCN-domain have the ECN | |||
field in their outermost IP header set to the appropriate codepoint. | field in their outermost IP header set to the appropriate codepoint. | |||
PCN-egress-nodes then guarantee that the ECN field of any packet | PCN-egress-nodes then guarantee that the ECN field of any packet | |||
leaving the PCN-domain has appropriate ECN semantics. This prevents | leaving the PCN-domain has appropriate ECN semantics. This prevents | |||
unintended leakage of ECN marks into or out of the PCN-domain, and | unintended leakage of ECN marks into or out of the PCN-domain, and | |||
thus reduces backward-compatibility issues. | thus reduces backward-compatibility issues. | |||
6.2. Backward Compatibility with the RFC5696 Encoding | 6.2. Backward Compatibility with the RFC5696 Encoding | |||
Section 5.1 of the PCN architecture gives general guidance on fault | ||||
detection and diagnosis [RFC5559], including management analysis of | ||||
PCN markings arriving at PCN-egress nodes to detect early signs of | ||||
potential faults. Because the PCN encoding has gone through an | ||||
obsoleted earlier stage [RFC5696], misconfiguration mistakes may be | ||||
more likely. Therefore extra monitoring, such as in the following | ||||
example, may be necessary to detect and diagnose potential problems: | ||||
Informational example: In a controlled-load edge-behaviour | ||||
scenario it could be worth the PCN-egress node detecting the onset | ||||
of excess-traffic marking without any prior threshold-marking. | ||||
This might indicate that an interior node has been wrongly | ||||
configured to mark only ETM (which would have been correct for the | ||||
single-marking edge-behaviour). | ||||
A PCN-node implemented to use the obsoleted RFC5696 encoding could | A PCN-node implemented to use the obsoleted RFC5696 encoding could | |||
conceivably have been configured so that the Threshold-meter function | conceivably have been configured so that the Threshold-meter function | |||
marked what is now defined as the ETM codepoint in the 3-in-1 | marked what is now defined as the ETM codepoint in the 3-in-1 | |||
encoding. However, there is no known deployment of this rather | encoding. However, there is no known deployment of this rather | |||
unlikely variant of RFC5696 and no reason to believe that such an | unlikely variant of RFC5696 and no reason to believe that such an | |||
implementation would ever have been built. Therefore, it seems safe | implementation would ever have been built. Therefore, it seems safe | |||
to ignore this issue. | to ignore this issue. | |||
7. IANA Considerations | 7. IANA Considerations | |||
End of changes. 16 change blocks. | ||||
23 lines changed or deleted | 50 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/ |