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/