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/