draft-ietf-pcn-3-in-1-encoding-05.txt   draft-ietf-pcn-3-in-1-encoding-06.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
Intended status: Standards Track Moncaster Internet Consulting Obsoletes: 5696 (if approved) Moncaster Internet Consulting
Expires: November 22, 2011 M. Menth Intended status: Standards Track M. Menth
University of Tuebingen Expires: January 11, 2012 University of Tuebingen
May 21, 2011 July 10, 2011
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-05 draft-ietf-pcn-3-in-1-encoding-06
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.
On every link in the PCN domain, the overall rate of the PCN-traffic The overall rate of the PCN-traffic is metered on every link in the
is metered, and PCN-packets are appropriately marked when certain PCN domain, and PCN-packets are appropriately marked when certain
configured rates are exceeded. Egress nodes provide decision points configured rates are exceeded. Egress nodes pass information about
with information about the PCN-marks of PCN-packets which allows them these PCN-marks to decision points which then decide whether to admit
to take decisions about whether to admit or block a new flow request, or block new flow requests or to terminate some already-admitted
and to terminate some already admitted flows during serious pre- flows during serious pre-congestion.
congestion.
This document specifies how PCN-marks are to be encoded into the IP This document specifies how PCN-marks are to be encoded into the IP
header by re-using the Explicit Congestion Notification (ECN) header by re-using the Explicit Congestion Notification (ECN)
codepoints within a PCN-domain. This encoding builds on the baseline codepoints within a PCN-domain. This encoding provides for up to
encoding of RFC5696 and provides for three different PCN marking three different PCN marking states using a single DSCP: not-marked
states using a single DSCP: not-marked (NM), threshold-marked (ThM) (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence,
and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN it is called the 3-in-1 PCN encoding. This document obsoletes
encoding. RFC5696.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 22, 2011. This Internet-Draft will expire on January 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Changes in This Version (to be removed by RFC Editor) . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 1.2. Changes in This Version (to be removed by RFC Editor) . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 7
3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 7
3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 8
3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 9
4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 9
5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN 4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 9
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 10
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN
6.1. Backward Compatibility with Pre-existing PCN Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Implementations . . . . . . . . . . . . . . . . . . . . . 9 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 10
6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 11
6.2.1. Use of Both Excess-Traffic-Marking and 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11
Threshold-Marking . . . . . . . . . . . . . . . . . . 10 5.2.2. Behaviour of PCN-interior Nodes Using Two
6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 10 PCN-markings . . . . . . . . . . . . . . . . . . . . . 11
6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10 5.2.3. Behaviour of PCN-interior Nodes Using One
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 PCN-marking . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.3. Behaviour of PCN-egress Nodes . . . . . . . . . . . . . . 12
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Backward Compatibility with the Baseline Encoding . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 12 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Co-existence of ECN and PCN (informative) . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 16
Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 18
Appendix C. Example Mapping between Encoding of PCN-Marks in
IP and in MPLS Shim Headers . . . . . . . . . . . . . 20
Appendix D. Rationale for different behaviours for single
marking schemes . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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
configured with reference rates. Threshold-marking marks all PCN generally configured with different reference rates. Threshold-
packets once their traffic rate on a link exceeds the configured marking marks all PCN packets once their traffic rate on a link
reference rate (PCN-threshold-rate). Excess-traffic-marking marks exceeds the configured reference rate (PCN-threshold-rate). Excess-
only those PCN packets that exceed the configured reference rate traffic-marking marks only those PCN packets that exceed the
(PCN-excess-rate). The PCN-excess-rate is typically larger than the configured reference rate (PCN-excess-rate). The PCN-excess-rate is
PCN-threshold-rate [RFC5559]. Egress nodes monitor the PCN-marks of typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes
received PCN-packets and provide information about the PCN-marks to monitor the PCN-marks of received PCN-packets and pass information
decision points which take decisions about flow admission and about these PCN-marks to decision points which then decide whether to
termination on this basis [I-D.ietf-pcn-cl-edge-behaviour], admit new flows or terminate existing flows
[I-D.ietf-pcn-sm-edge-behaviour]. [I-D.ietf-pcn-cl-edge-behaviour], [I-D.ietf-pcn-sm-edge-behaviour].
The baseline encoding defined in [RFC5696] describes how two PCN The baseline encoding defined in [RFC5696] described how two PCN
marking states (Not-marked and PCN-Marked) can be encoded using a marking states (Not-marked and PCN-Marked) could be encoded into the
single Diffserv codepoint. It also provides an experimental IP header using a single Diffserv codepoint. It also provided an
codepoint (EXP), along with guidelines for use of that codepoint. To experimental codepoint (EXP), along with guidelines for the use of
support the application of two different marking algorithms in a PCN- that codepoint. Two PCN marking states are sufficient for the Single
domain, for example as required in [I-D.ietf-pcn-cl-edge-behaviour], Marking edge behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However,
three PCN marking states are needed. This document describes an PCN-domains utilising the controlled load edge behaviour
extension to the baseline encoding that uses the EXP codepoint to [I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states.
provide a third PCN marking state in the IP header, still using a This document extends the baseline encoding by redefining the EXP
single Diffserv codepoint. This encoding scheme is called "3-in-1 codepoint to provide a third PCN marking state in the IP header,
PCN encoding". still using a single Diffserv codepoint. This encoding scheme is
therefore called the "3-in-1 PCN encoding". It obsoletes the
baseline encoding [RFC5696], which provides only a sub-set of the
same capabilities.
This document only concerns the PCN wire protocol encoding for all IP The full version of this encoding requires any tunnel endpoint within
the PCN-domain to support the normal tunnelling rules defined in
[RFC6040]. There is one limited exception to this constraint where
the PCN-domain only uses the excess-traffic-marking behaviour and
where the threshold-marking behaviour is deactivated. This is
discussed in Section 5.2.3.1.
This document only concerns the PCN wire protocol encoding for IP
headers, whether IPv4 or IPv6. It makes no changes or headers, whether IPv4 or IPv6. It makes no changes or
recommendations concerning algorithms for congestion marking or recommendations concerning algorithms for congestion marking or
congestion response. Other documents define the PCN wire protocol congestion response. Other documents will define the PCN wire
for other header types. For example, the MPLS encoding is defined in protocol for other header types. Appendix C discusses a possible
[RFC5129] and Appendix A of that document provides an informative mapping between IP and MPLS.
example for a mapping between the encodings in IP and in MPLS.
1.1. Changes in This Version (to be removed by RFC Editor) 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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-05 to -06:
* Draft re-written to obsolete baseline encoding [RFC5696].
* New section defining utilising this encoding for single
marking. Added an appendix explaining an apparent
inconsistency relating to single marking.
* 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: From draft-ietf-pcn-3-in-1-encoding-04 to -05:
* Draft moved to standards track as per working group * Draft moved to standards track as per working group
discussions. discussions.
* Added Appendix A discussing ECN handling in the PCN-domain. * Added Appendix B discussing ECN handling in the PCN-domain.
* Clarified that this document modifies [RFC5696]. * Clarified that this document modifies [RFC5696].
* .......
From draft-ietf-pcn-3-in-1-encoding-03 to -04: From draft-ietf-pcn-3-in-1-encoding-03 to -04:
* Updated document to reflect RFC6040. * Updated document to reflect RFC6040.
* Re-wrote introduction. * Re-wrote introduction.
* Re-wrote section on applicability. * Re-wrote section on applicability.
* Re-wrote section on choosing encoding scheme. * Re-wrote section on choosing encoding scheme.
skipping to change at page 5, line 26 skipping to change at page 7, line 5
* Introduction altered to include new template description of * Introduction altered to include new template description of
PCN. PCN.
* References updated. * References updated.
* Terminology brought into line with [RFC5670]. * Terminology brought into line with [RFC5670].
* Minor corrections. * Minor corrections.
2. Requirements Language 2. Definitions and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Terminology 2.1. Terminology
General PCN-related terminology is defined in the PCN architecture The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node,
[RFC5559], and terminology specific to packet encoding is defined in PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and PCN-
the PCN baseline encoding [RFC5696]. Additional terminology is marking are used as defined in [RFC5559]. The following additional
defined below. 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.
3. Requirements for and Applicability of 3-in-1 PCN Encoding PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating
packets for which the ECN field is used to carry PCN-markings
rather than [RFC3168] markings (see Appendix A).
3.1. PCN Requirements Threshold-marked codepoint: a codepoint that indicates packets that
have been marked at a PCN-interior-node as a result of an
indication from the threshold-metering function [RFC5670].
Abbreviated to ThM.
Excess-traffic-marked codepoint: a codepoint that indicates packets
that have been marked at a PCN-interior-node as a result of an
indication from the excess-traffic-metering function [RFC5670].
Abbreviated to ETM.
Not-marked codepoint: a codepoint that indicates PCN-packets but
that are not PCN-marked. Abbreviated to NM.
not-PCN codepoint: a codepoint that indicates packets that are not
PCN-packets.
2.2. List of Abbreviations
The following abbreviations are used in this document:
o AF = Assured Forwarding [RFC2597]
o CE = Congestion Experienced [RFC3168]
o CS = Class Selector [RFC2474]
o DSCP = Diffserv codepoint
o ECN = Explicit Congestion Notification [RFC3168]
o ECT = ECN Capable Transport [RFC3168]
o EF = Expedited Forwarding [RFC3246]
o ETM = Excess-traffic-marked
o EXP = Experimental
o IP = Internet protocol
o NM = Not-marked
o PCN = Pre-Congestion Notification
o ThM = Threshold-marked
3. Definition of 3-in-1 PCN Encoding
The 3-in-1 PCN encoding scheme allows for two or three PCN-marking
states to be encoded within the IP header. The full encoding is
shown in Figure 1.
+--------+----------------------------------------------------+
| | Codepoint in ECN field of IP header |
| DSCP | <RFC3168 codepoint name> |
| +--------------+-------------+-------------+---------+
| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
+--------+--------------+-------------+-------------+---------+
| DSCP n | Not-PCN | NM | ThM | ETM |
+--------+--------------+-------------+-------------+---------+
Figure 1: 3-in-1 PCN Encoding
As mentioned above, the 3-in-1 PCN encoding is an extension of the
baseline encoding [RFC5696]. Like the baseline encoding it uses a
combination of a PCN-compatible DSCP (DSCP n in Figure 1) and the ECN
field for the encoding of PCN-marks. Appendix A discusses the choice
of suitable DSCPs. The PCN-marks have the following meaning.
Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not
subject to PCN metering and marking.
NM: Not-marked. Indicates a PCN-packet that has not yet been marked
by any PCN marker.
ThM: Threshold-marked. Indicates a PCN-packet that has been marked
by a threshold-marker [RFC5670].
ETM: Excess-traffic-marked. Indicates a PCN-packet that has been
marked by an excess-traffic-marker [RFC5670].
4. Requirements for and Applicability of 3-in-1 PCN Encoding
4.1. PCN Requirements
In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes
control packets entering a PCN-domain. Packets belonging to PCN- control packets entering a PCN-domain. Packets belonging to PCN-
controlled flows are subject to PCN-metering and -marking, and PCN- controlled flows are subject to PCN-metering and -marking, and PCN-
ingress-nodes mark them as Not-marked (PCN-colouring). Any node in ingress-nodes mark them as Not-marked (PCN-colouring). Any node in
the PCN-domain may perform PCN-metering and -marking and mark PCN- the PCN-domain may perform PCN-metering and -marking and mark PCN-
packets if needed. There are two different metering and marking packets if needed. There are two different metering and marking
schemes: threshold-marking and excess-traffic-marking [RFC5670]. behaviours: threshold-marking and excess-traffic-marking [RFC5670].
Some edge behaviors require only a single marking scheme Some edge behaviors require only a single marking behaviour
[I-D.ietf-pcn-sm-edge-behaviour], others require both [I-D.ietf-pcn-sm-edge-behaviour], others require both
[I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN [I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN
marking states are needed: not-marked (NM) to indicate not-marked marking states are needed: not-marked (NM) to indicate not-marked
packets, threshold-marked (ThM) to indicate packets marked by the packets, threshold-marked (ThM) to indicate packets marked by the
threshold-marker, and excess-traffic-marked (ETM) to indicate packets threshold-marker, and excess-traffic-marked (ETM) to indicate packets
marked by the excess-traffic-marker [RFC5670]. Threshold-marking and marked by the excess-traffic-marker [RFC5670]. Threshold-marking and
excess-traffic-marking are configured to start marking packets at excess-traffic-marking are configured to start marking packets at
different load conditions, so one marking scheme indicates more different load conditions, so one marking behaviour indicates more
severe pre-congestion than the other. Therefore, a fourth PCN severe pre-congestion than the other. Therefore, a fourth PCN
marking state indicating that a packet is marked by both markers is marking state indicating that a packet is marked by both markers is
not needed. However a fourth codepoint is required to indicate not needed. However a fourth codepoint is required to indicate
packets that are not PCN-capable (the not-PCN codepoint). packets that do not use PCN (the not-PCN codepoint).
In all current PCN edge behaviors that use two marking schemes In all current PCN edge behaviors that use two marking behaviours
[RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking
is configured with a larger reference rate than threshold-marking. is configured with a larger reference rate than threshold-marking.
We take this as a rule and define excess-traffic-marked as a more We take this as a rule and define excess-traffic-marked as a more
severe PCN-mark than threshold-marked. severe PCN-mark than threshold-marked.
3.2. Requirements Imposed by Baseline Encoding 4.2. Requirements Imposed by Tunnelling
The baseline encoding scheme [RFC5696] was defined so that it could [RFC6040] defines rules for the encapsulation and decapsulation of
be extended to accommodate an additional marking state. It provides ECN markings within IP-in-IP tunnels. The publication of RFC6040
rules to embed the encoding of two PCN states in the IP header. removed the tunnelling constraints that existed when the baseline
Figure 1 shows the structure of the former type-of-service field. It encoding [RFC5696] was written (see section 3.3.2 of
contains the 6-bit Differentiated Services (DS) field that holds the [I-D.ietf-pcn-encoding-comparison]).
DS codepoint (DSCP) [RFC2474] and the 2-bit ECN field [RFC3168].
0 1 2 3 4 5 6 7 Nonetheless, there is still a problem if there are any legacy (pre-
+-----+-----+-----+-----+-----+-----+-----+-----+ RFC6040) decapsulating tunnel endpoints within a PCN domain. If a
| DS FIELD | ECN FIELD | PCN node Threshold-marks the outer header of a tunnelled packet with
+-----+-----+-----+-----+-----+-----+-----+-----+ a Not-marked codepoint on the inner header, the legacy decapsulator
will revert the Threshold-marking to Not-marked. The rules on
applicability in Section 4.3 below are designed to avoid this
problem.
Figure 1: Structure of the former type-of-service field in IP 4.3. Applicability of 3-in-1 PCN Encoding
Baseline encoding defines that the DSCP must be set to a PCN- The 3-in-1 encoding is applicable in situations where two marking
compatible DSCP n and the ECN-field [RFC3168] indicates the specific behaviours are being used in the PCN-domain. The 3-in-1 encoding can
PCN-mark. Baseline encoding offers four possible encoding states also be used with only one marking behaviour, in which case one of
within a single DSCP with the following restrictions. the codepoints MUST NOT be used throughout the PCN-domain (see
Section 5.2.3).
o Codepoint `00' (not-ECT) is used to indicate non-PCN traffic as For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP
"not-PCN". This allows both PCN and non-PCN traffic to use the and IPsec) within the PCN-domain MUST comply with the ECN
same DSCP. encapsulation and decapsulation rules set out in [RFC6040] (see
Section 4.2). There is one exception to this rule outlined next.
o Codepoint `10' (ECT(0)) is used to indicate Not-marked PCN It may not be possible to upgrade every pre-RFC6040 tunnel endpoint
traffic. within a PCN-domain. In such cirsumstances a limited version of the
3-in-1 encoding can still be used but only under the following
stringent condition. If any pre-RFC6040 tunnel endpoint exists
within a PCN-domain then every PCN-node in the PCN-domain MUST be
configured so that it never sets the ThM codepoint. The behaviour of
PCN-interior nodes in this case is defined in Section 5.2.3.1. In
all other situations where legacy tunnel endpoints might be present
within the PCN domain, the 3-in-1 encoding is not applicable.
o Codepoint `11' (CE) is used to indicate the most severe PCN-mark. 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding
o Codepoint `01' (ECT(1)) is available for experimental use and may As mentioned in Section 4.3 above, all PCN-nodes MUST comply with
be re-used by other PCN encodings such as the presently defined [RFC6040].
3-in-1 PCN encoding (subject to the rules defined in [RFC5696]).
[RFC6040] defines rules for the encapsulation and decapsulation of 5.1. PCN-ingress Node Behaviour
ECN markings within IP-in-IP tunnels. This RFC removes some of the
constraints that existed when [RFC5696] was written. Happily the
rules for use of the EXP codepoint are fully compatible with
[RFC6040]. In particular, the relative severity of each marking is
the same: CE (PM) is more severe than ECT(1) (EXP) is more severe
than ECT(0) (NM). This is discussed in more detail in both the
baseline encoding document [RFC5696] and in
[I-D.ietf-pcn-encoding-comparison].
3.3. Applicability of 3-in-1 PCN Encoding PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint.
To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are
already defined for use with admission-controlled traffic.
Appendix A gives guidance to implementors on suitable DSCPs.
Guidelines for mixing traffic types within a PCN-domain are given in
[RFC5670].
The 3-in-1 encoding is applicable in situations where two marking If a packet arrives at the PCN-ingress-node that shares a PCN-
schemes are being used in the PCN-domain. In some circumstances it compatible DSCP and is not a PCN-packet, the PCN-ingress MUST mark it
can also be used in PCN-domains with only a single marking scheme in as not-PCN.
use. Further guidance on choosing an encoding scheme can be found in
Section 6.2. All nodes within the PCN-domain MUST be fully compliant
with the ECN encapsulation rules set out in [RFC6040]. As such the
encoding is not applicable in situations where legacy tunnels might
exist.
4. Definition of 3-in-1 PCN Encoding If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress MUST
change the PCN codepoint to Not-marked.
The 3-in-1 PCN encoding scheme is an extension of the baseline If a PCN-packet arrives at the PCN-ingress-node with its ECN field
encoding scheme defined in [RFC5696]. The PCN requirements and the already set to a value other than not-ECT, then appropriate action
extension rules for baseline encoding presented in the previous MUST be taken to meet the requirements of [RFC4774]. The simplest
section determine how PCN encoding states are carried in the IP appropriate action is to just drop such packets. However, this is a
headers. This is shown in Figure 2. drastic action that an operator may feel is undesirable. Appendix B
provides more information and summarises other alternative actions
that might be taken.
+--------+----------------------------------------------------+ 5.2. PCN-interior Node Behaviour
| | Codepoint in ECN field of IP header |
| DSCP | <RFC3168 codepoint name> |
| +--------------+-------------+-------------+---------+
| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
+--------+--------------+-------------+-------------+---------+
| DSCP n | Not-PCN | NM | ThM | ETM |
+--------+--------------+-------------+-------------+---------+
Figure 2: 3-in-1 PCN Encoding
Like baseline encoding, 3-in-1 PCN encoding also uses a PCN 5.2.1. Behaviour Common to all PCN-interior Nodes
compatible DSCP n and the ECN field for the encoding of PCN-marks.
The PCN-marks have the following meaning.
Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not Interior nodes MUST NOT change not-PCN to any other codepoint.
subject to PCN metering and marking.
NM: Not-marked. Indicates a PCN-packet that has not yet been marked Interior nodes MUST NOT change NM to not-PCN.
by any PCN marker.
ThM: Threshold-marked. Indicates a PCN-packet that has been marked Interior nodes MUST NOT change ThM to NM or not-PCN.
by a threshold-marker [RFC5670].
ETM: Excess-traffic-marked. Indicates a PCN-packet that has been Interior nodes MUST NOT change ETM to any other codepoint.
marked by an excess-traffic-marker [RFC5670].
5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding 5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings
To be compliant with the 3-in-1 PCN Encoding, an PCN interior node If the threshold-meter function indicates a need to mark the packet,
behaves as follows: the PCN-interior node MUST change NM to ThM.
o It MUST change NM to ThM if the threshold-meter function indicates If the excess-traffic-meter function indicates a need to mark the
a need to mark the packet; packet:
o It MUST change NM or ThM to ETM if the excess-traffic-meter o the PCN-interior node MUST change NM to ETM;
function indicates a need to mark the packet;
o It MUST NOT change not-PCN to NM, ThM, or ETM; o the PCN-interior node MUST change ThM to ETM.
o It MUST NOT change a NM, ThM, or ETM to not-PCN; If both the threshold meter and the excess-traffic meter indicate the
need to mark a packet, the excess traffic marking rules MUST take
priority.
o It MUST NOT change ThM to NM; 5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking
o It MUST NOT change ETM to ThM or to NM; Some PCN edge behaviours require only one PCN-marking within the PCN-
domain. The Single Marking edge behaviour
[I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark
packets using the excess-traffic-meter function [RFC5670]. It is
possible that future schemes may require only the threshold-meter
function. Observant readers may spot an apparent inconsistency
between the two following cases. Appendix D explains the rationale
behind this inconsistency.
In other words, a PCN interior node MUST NOT mark PCN-packets into 5.2.3.1. Marking using only the Excess-traffic-meter Function
non-PCN packets and vice-versa, and it may increase the severity of
the PCN-mark of a PCN-packet, but it MUST NOT decrease it.
6. Backward Compatibility The threshold-traffic-meter function SHOULD be disabled and MUST NOT
trigger any packet marking.
Discussion of backward compatibility between PCN encoding schemes and The PCN-interior node SHOULD raise a management alarm if it receives
previous uses of the ECN field is given in Section 6 of [RFC5696]. a ThM packet, but the frequency of such alarms SHOULD be limited.
6.1. Backward Compatibility with Pre-existing PCN Implementations If the excess-traffic-meter function indicates a need to mark the
packet:
This encoding complies with the rules for extending the baseline PCN o the PCN-interior node MUST change NM to ETM;
encoding schemes in Section 5 of [RFC5696].
The term "compatibility" is meant in the following sense. It is o the PCN-interior node MUST change ThM to ETM. It SHOULD also
possible to operate nodes with baseline encoding [RFC5696] and 3-in-1 raise an alarm as above.
encoding in the same PCN domain. The nodes with baseline encoding
MUST perform excess-traffic-marking because the 11 codepoint of
3-in-1 encoding also means excess-traffic-marked. PCN-boundary-nodes
of such domains are required to interpret the full 3-in-1 encoding
and not just baseline encoding, otherwise they cannot interpret the
01 codepoint.
Using nodes that perform only excess-traffic-marking may make sense 5.2.3.2. Marking using only the Threshold-meter Function
in networks using the CL edge behavior
[I-D.ietf-pcn-cl-edge-behaviour]. Such nodes are able to notify the
egress only about severe pre-congestion when traffic needs to be
terminated. This seems reasonable for locations that are not
expected to see any pre-congestion, but excess-traffic-marking gives
them a means to terminate traffic if unexpected overload occurs.
6.2. Recommendations for the Use of PCN Encoding Schemes The excess-traffic-meter function SHOULD be disabled and MUST NOT
trigger any packet marking.
NOTE: This sub-section is informative not normative. The PCN-interior node SHOULD raise a management alarm if it receives
an ETM packet, but the frequency of such alarms SHOULD be limited.
When deciding which PCN encoding is suitable an operator needs to If the threshold-meter function indicates a need to mark the packet:
take account of how many PCN states need to be encoded. The
following table gives guidelines on which encoding to use with either
threshold-marking, excess-traffic marking or both.
+------------------------+--------------------------------+ o the PCN-interior node MUST change NM to ThM;
| Marking schemes in use | Recommended encoding scheme |
+------------------------+--------------------------------+
| Only threshold-marking | Baseline encoding [RFC5696] |
+------------------------+--------------------------------+
| Only excess-traffic- | Baseline encoding [RFC5696] |
| marking | or 3-in-1 PCN encoding |
+------------------------+--------------------------------+
| Threshold-marking and | 3-in-1 PCN encoding |
| excess-traffic-marking | |
+------------------------+--------------------------------+
Figure 3: Guidelines for choosing PCN encoding schemes o the PCN-interior node MUST NOT change ETM to any other codepoint.
It SHOULD raise an alarm as above.
6.2.1. Use of Both Excess-Traffic-Marking and Threshold-Marking 5.3. Behaviour of PCN-egress Nodes
If both excess-traffic-marking and threshold-marking are enabled in a A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all
PCN-domain, 3-in-1 encoding should be used as described in this packets it forwards out of the PCN-domain.
document.
6.2.2. Unique Use of Excess-Traffic-Marking The only exception to this is if the PCN-egress-node is certain that
revealing other codepoints outside the PCN-domain won't contravene
the guidance given in [RFC4774]. For instance, if the PCN-ingress-
node has explicitly informed the PCN-egress-node that this flow is
ECN-capable, then it might be safe to expose other codepoints.
Appendix B gives details of how such schemes might work, but such
schemes are currently experimental.
If only excess-traffic-marking is enabled in a PCN-domain, baseline If the PCN-domain is configured to use only excess-traffic marking,
encoding or 3-in-1 encoding may be used. They lead to the same the PCN-egress node MUST treat ThM as ETM and if only threshold-
encoding because PCN-boundary nodes will interpret baseline "PCN- marking is used it should treat ETM as ThM. However it SHOULD raise
marked (PM)" as "excess-traffic-marked (ETM)". a management alarm in either instance since this means there is some
misconfiguration in the PCN-domain.
6.2.3. Unique Use of Threshold-Marking 6. Backward Compatibility
No scheme is currently proposed that solely uses threshold-marking. 6.1. Backward Compatibility with ECN
If such a scheme is proposed, the choice of encoding scheme will
depend on whether nodes are compliant with [RFC6040] or not. Where BCP 124 [RFC4774] gives guidelines for specifying alternative
it is certain that all nodes in the PCN-domain are compliant then semantics for the ECN field. It sets out a number of factors to be
either 3-in-1 encoding or baseline encoding are suitable. If legacy taken into consideration. It also suggests various techniques to
tunnel decapsulators exist within the PCN-domain then baseline allow the co-existence of default ECN and alternative ECN semantics.
encoding SHOULD be used. The encoding specified in this document uses one of those techniques;
it defines PCN-compatible Diffserv codepoints as no longer supporting
the default ECN semantics. As such, this document is compatible with
BCP 124.
On its own, the 3-in-1 encoding cannot support both ECN marking end-
to-end (e2e) and PCN-marking within a PCN-domain. Appendix B
discusses possible ways to do this, e.g. by carrying e2e ECN across a
PCN-domain within the inner header of an IP-in-IP tunnel. Although
Appendix B recommends various approaches over others, it is merely
informative and all such schemes are beyond the normative scope of
this document.
In any PCN deployment, traffic can only enter the PCN-domain through
PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress-
nodes ensure that any packets entering the PCN-domain have the ECN
field in their outermost IP header set to the appropriate PCN
codepoint. PCN-egress-nodes then guarantee that the ECN field of any
packet leaving the PCN-domain has appropriate ECN semantics. This
prevents unintended leakage of ECN marks into or out of the PCN-
domain, and thus reduces backward-compatibility issues.
6.2. Backward Compatibility with the Baseline Encoding
A PCN node implemented to use the obsoleted baseline 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, thre is no known deployment of such an
implementation 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 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
8. Security Considerations 8. Security Considerations
The security concerns relating to this extended PCN encoding are the PCN-marking only carries a meaning within the confines of a PCN-
same as those in [RFC5696]. In summary, PCN-boundary nodes are domain. This encoding document is intended to stand independently of
responsible for ensuring inappropriate PCN markings do not leak into the architecture used to determine how specific packets are
or out of a PCN domain, and the current phase of the PCN architecture authorised to be PCN-marked, which will be described in separate
assumes that all the nodes of a PCN-domain are entirely under the documents on PCN-boundary-node behaviour.
control of a single operator, or a set of operators who trust each
other.
Given the only difference between the baseline encoding and the This document assumes the PCN-domain to be entirely under the control
present 3-in-1 encoding is the use of the 01 codepoint, no new of a single operator, or a set of operators who trust each other.
security issues are raised, as this codepoint was already available However, future extensions to PCN might include inter-domain versions
for experimental use in the baseline encoding. where trust cannot be assumed between domains. If such schemes are
proposed, they must ensure that they can operate securely despite the
lack of trust. However, such considerations are beyond the scope of
this document.
One potential security concern is the injection of spurious PCN-marks
into the PCN-domain. However, these can only enter the domain if a
PCN-ingress-node is misconfigured. The precise impact of any such
misconfiguration will depend on which of the proposed PCN-boundary-
node behaviours is used, but in general spurious marks will lead to
admitting fewer flows into the domain or potentially terminating too
many flows. In either case, good management should be able to
quickly spot the problem since the overall utilisation of the domain
will rapidly fall.
9. Conclusions 9. 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.
The use of this PCN encoding scheme presupposes that any tunnels in In general, the use of this PCN encoding scheme presupposes that any
the PCN region have been updated to comply with [RFC6040]. tunnel endpoints within the PCN-domain comply with [RFC6040].
10. Acknowledgements 10. Acknowledgements
Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan and Georgios Many thanks to Phil Eardley for providing extensive feedback,
Karaginannis for reviewing this document. critcism and advice. Thanks also to Teco Boot, Kwok Ho Chan,
Ruediger Geib, Georgios Karaginannis and everyone else who has
commented on the document.
11. Comments Solicited 11. Comments Solicited
To be removed by RFC Editor: Comments and questions are encouraged To be removed by RFC Editor: Comments and questions are encouraged
and very welcome. They can be addressed to the IETF Congestion and and very welcome. They can be addressed to the IETF Congestion and
Pre-Congestion working group mailing list <pcn@ietf.org>, and/or to Pre-Congestion working group mailing list <pcn@ietf.org>, and/or to
the authors. the authors.
12. References 12. References
skipping to change at page 11, line 42 skipping to change at page 15, line 28
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009. Architecture", RFC 5559, June 2009.
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
Nodes", RFC 5670, November 2009. Nodes", RFC 5670, November 2009.
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information",
RFC 5696, November 2009.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, May 2010.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010. Notification", RFC 6040, November 2010.
12.2. Informative References 12.2. Informative References
[I-D.ietf-pcn-cl-edge-behaviour] [I-D.ietf-pcn-cl-edge-behaviour]
Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
Taylor, "PCN Boundary Node Behaviour for the Controlled Taylor, "PCN Boundary Node Behaviour for the Controlled
Load (CL) Mode of Operation", Load (CL) Mode of Operation",
draft-ietf-pcn-cl-edge-behaviour-08 (work in progress), draft-ietf-pcn-cl-edge-behaviour-09 (work in progress),
December 2010. June 2011.
[I-D.ietf-pcn-encoding-comparison] [I-D.ietf-pcn-encoding-comparison]
Karagiannis, G., Chan, K., Moncaster, T., Menth, M., Karagiannis, G., Chan, K., Moncaster, T., Menth, M.,
Eardley, P., and B. Briscoe, "Overview of Pre-Congestion Eardley, P., and B. Briscoe, "Overview of Pre-Congestion
Notification Encoding", Notification Encoding",
draft-ietf-pcn-encoding-comparison-05 (work in progress), draft-ietf-pcn-encoding-comparison-06 (work in progress),
April 2011. June 2011.
[I-D.ietf-pcn-sm-edge-behaviour] [I-D.ietf-pcn-sm-edge-behaviour]
Charny, A., Karagiannis, G., Menth, M., and T. Taylor, Charny, A., Karagiannis, G., Menth, M., and T. Taylor,
"PCN Boundary Node Behaviour for the Single Marking (SM) "PCN Boundary Node Behaviour for the Single Marking (SM)
Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-05 Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-06
(work in progress), December 2010. (work in progress), June 2011.
Appendix A. Co-existence of ECN and PCN (informative) [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124,
RFC 4774, November 2006.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
DiffServ Service Classes", RFC 5127, February 2008.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009.
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information",
RFC 5696, November 2009.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, May 2010.
Appendix A. Choice of Suitable DSCPs
This appendix is informative, not normative.
The PCN working group chose not to define a single DSCP for use with
PCN for several reasons. Firstly, the PCN mechanism is applicable to
a variety of different traffic classes. Secondly, Standards Track
DSCPs are in increasingly short supply. Thirdly, PCN is not a
scheduling behaviour -- rather, it should be seen as being a marking
behaviour similar to ECN but intended for inelastic traffic. The
choice of 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 all the links making up that domain. In PCN-domains
with sufficient aggregation, the appropriate DSCPs would currently be
those for the Real-Time Treatment Aggregate [RFC5127]. The PCN
working group suggests using admission control for the following
service classes (defined in [RFC4594]):
o Telephony (EF)
o Real-time interactive (CS4)
o Broadcast Video (CS3)
o Multimedia Conferencing (AF4)
CS5 is excluded from this list since PCN is not expected to be
applied to signalling traffic. PCN can also be applied to the VOICE-
ADMIT codepoint defined in [RFC5865].
PCN-marking is intended to provide a scalable admission-control
mechanism for traffic with a high degree of statistical multiplexing.
PCN-marking would therefore be appropriate to apply to traffic in the
above classes, but only within a PCN-domain containing sufficiently
aggregated traffic. In such cases, the above service classes may
well all be subject to a single forwarding treatment (treatment
aggregate [RFC5127]). However, this does not imply all such IP
traffic would necessarily be identified by one DSCP -- each service
class might keep a distinct DSCP within the highly aggregated region
[RFC5127].
Additional service classes may be defined for which admission control
is appropriate, whether through some future standards action or
through local use by certain operators, e.g., the Multimedia
Streaming service class (AF3). This document does not preclude the
use of PCN in more cases than those listed above.
Note: The above discussion is informative not normative, as operators
are ultimately free to decide whether to use admission control for
certain service classes and whether to use PCN as their mechanism of
choice.
Appendix B. Co-existence of ECN and PCN
This appendix is informative, not normative.
The PCN encoding described in this document re-uses the bits of the The PCN encoding described in this document re-uses the bits of the
ECN field in the IP header. Consequently, this disables ECN within ECN field in the IP header. Consequently, this disables ECN within
the PCN domain. Appendix B of [RFC5696] included advice on handling the PCN domain. Appendix B of [RFC5696] (obsoleted) included advice
ECN traffic within a PCN-domain. This appendix clarifies that on handling ECN traffic within a PCN-domain. This appendix
advice. reiterates and clarifies that advice.
For the purposes of this appendix we define two forms of traffic that For the purposes of this appendix we define two forms of traffic that
might arrive at a PCN-ingress node. These are Admission-controlled might arrive at a PCN-ingress node. These are Admission-controlled
traffic and Non-admission-controlled traffic. traffic and Non-admission-controlled traffic.
Admission-controlled traffic will be remarked to the PCN-compatible Admission-controlled traffic will be remarked to a PCN-compatible
DSCP by the PCN-ingress node. Two mechanisms can be used to identify DSCP by the PCN-ingress node. Two mechanisms can be used to identify
such traffic: such traffic:
a. flow signalling associates a filterspec with a need for admission a. flow signalling associates a filterspec with a need for admission
control (e.g. through RSVP or some equivalent message down from a control (e.g. through RSVP or some equivalent message, e.g. from
SIP server to the ingress), and the PCN-ingress remarks traffic a SIP server to the ingress), and the PCN-ingress remarks traffic
matching that filterspec to a PCN-compatible DSCP, as its chosen matching that filterspec to a PCN-compatible DSCP, as its chosen
admission control mechanism. admission control mechanism.
b. Traffic arrives with a DSCP that implies it requires admission b. Traffic arrives with a DSCP that implies it requires admission
control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time,
Broadcast TV when used for video on demand, and Multimedia Broadcast TV when used for video on demand, and Multimedia
Conferencing [RFC4594][RFC5865]. Conferencing [RFC4594][RFC5865].
All other traffic can be thought of as Non-admission-controlled. All other traffic can be thought of as Non-admission-controlled (and
However such traffic may still need to share the same DSCP as the therefore outside the scope of PCN). However such traffic may still
Admission-controlled traffic. This may be due to policy (for need to share the same DSCP as the Admission-controlled traffic.
instance if it is high priority voice traffic), or may be because This may be due to policy (for instance if it is high priority voice
there is a shortage of local DSCPs. traffic), or may be because there is a shortage of local DSCPs.
ECN [RFC3168] is an end-to-end congestion notification mechanism. As ECN [RFC3168] is an end-to-end congestion notification mechanism. As
such it is possible that some traffic entering the PCN-domain may such it is possible that some traffic entering the PCN-domain may
also be ECN capable The following lists the four cases for how e2e also be ECN capable.
ECN traffic may wish to be treated while crossing a PCN domain:
Unless specified otherwise, for any of the cases in the list below,
an IP-in-IP tunnel can be used to preserve ECN markings across the
PCN domain. However the tunnelling action should be applied wholly
outside the PCN-domain as illustrated in the following figure:
, . . . . . PCN-domain . . . . . .
. ,--------. ,--------. .
. _| PCN- |___________________| PCN- |_ .
. / | ingress | | egress | \ .
.| '---------' '--------' |.
| . . . . . . . . . . . . . . .|
,--------. ,--------.
_____| Tunnel | | Tunnel |____
| Ingress | - - ECN preserved inside tunnel - - | Egress |
'---------' '--------'
Figure 2: Separation of tunneling and PCN actions
There are four cases for how e2e ECN traffic may wish to be treated
while crossing a PCN domain:
ECN capable traffic that does not require admission control and does ECN capable traffic that does not require admission control and does
not carry a DSCP that the PCN-ingress is using for PCN-capable not carry a DSCP that the PCN-ingress is using for PCN-capable
traffic. This requires no action. traffic. This requires no action.
ECN capable traffic that does not require admission control but ECN capable traffic that does not require admission control but
carries a DSCP that the PCN-ingress is using for PCN-capable carries a DSCP that the PCN-ingress is using for PCN-capable
traffic. There are two options. traffic. There are two options.
* The ingress maps the DSCP to a local DSCP with the same * The ingress maps the DSCP to a local DSCP with the same
scheduling PHB as the original DSCP, and the egress re-maps it scheduling PHB as the original DSCP, and the egress re-maps it
to the original PCN-compatible DSCP. to the original PCN-compatible DSCP.
* The ingress tunnels the traffic, setting not-PCN in the outer * The ingress tunnels the traffic, setting not-PCN in the outer
header; note that this turns off ECN for this traffic within header; note that this turns off ECN for this traffic within
the PCN domain. the PCN domain.
skipping to change at page 14, line 25 skipping to change at page 20, line 5
ECN-capable Admission-controlled traffic: There are two options. ECN-capable Admission-controlled traffic: There are two options.
* The PCN-ingress places this traffic in a tunnel with a PCN- * The PCN-ingress places this traffic in a tunnel with a PCN-
compatible DSCP in the outer header. The PCN-egress zeroes the compatible DSCP in the outer header. The PCN-egress zeroes the
ECN-field before decapsulation. ECN-field before decapsulation.
* The PCN-ingress drops CE-marked packets and the PCN-egress * The PCN-ingress drops CE-marked packets and the PCN-egress
zeros the ECN field of all PCN packets. zeros the ECN field of all PCN packets.
The second option is not recommended unless tunnelling is not The second option is emphatically not recommended, unless perhaps
possible for some reason.. as a last resort if tunnelling is not possible for some
insurmountable reason.
ECN-capable Admission-controlled where the e2e transport somehow ECN-capable Admission-controlled traffic where the e2e transport
indicates that it wants to see PCN marks: NOTE this is currently somehow indicates that it wants to see PCN marks: NOTE this is
experimental only. currently tentative only.
Schemes have been suggested where PCN marks may be leaked out of Schemes have been suggested where PCN marks may be leaked out of
the PCN-domain and used by the end hosts to modify realtime data the PCN-domain and used by the end hosts to modify realtime data
rates. Currently all such schemes are experimental and the rates. Currently all such schemes require further study and the
following is for guidance only. following is for guidance only.
The PCN-ingress needs to tunnel the traffic using [RFC6040]. The The PCN-ingress needs to tunnel the traffic, taking care to comply
PCN-egress should not zero the ECN field, and the tunnel egress with [RFC6040]. In this case the PCN-egress should not zero the
should use [RFC6040] normal mode (preserving any PCN-marking). ECN field, and then the [RFC6040] tunnel egress will preserve any
Note that this may turn ECT(0) into ECT(1) and so is not PCN-marking. Note that a PCN interior node may turn ECT(0) into
compatible with the experimental ECN nonce [RFC3540]. ECT(1), which would not be compatible with the (currently
experimental) ECN nonce [RFC3540].
In the list above any form of IP-in-IP tunnel can be used unless Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in
specified otherwise. NB, We assume a logical separation of tunneling MPLS Shim Headers
and PCN actions in both PCN-ingress and PCN-egress nodes. That is,
any tunneling action happens wholly outside the PCN-domain as
illustrated in the following figure:
, . . . . . PCN-domain . . . . . . This appendix is informative not normative.
. ,--------. ,--------. .
. _| PCN- |___________________| PCN- |_ .
. / | ingress | | egress | \ .
.| '---------' '--------' |.
| . . . . . . . . . . . . . . .|
,--------. ,--------.
_____| Tunnel | | Tunnel |____
| Ingress | - - ECN preserved inside tunnel - - | Egress |
'---------' '--------'
Figure 4: Separation of tunneling and PCN actions 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
make the DS field information accessible in the MPLS header.
However, the MPLS shim header has only a 3-bit traffic class (TC)
field [RFC5462] providing for 8 codepoints. The operator has the
freedom to define a site-local mapping of a subset of the 64
codepoints of the DS field to the 8 codepoints in the TC field.
[RFC5129] describes how ECN markings in the IP header can also be
mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129]
gives an informative description of how to support PCN in MPLS by
extending the way MPLS supports ECN. But [RFC5129] was written while
PCN specifications were in early draft stages. The following
provides a clearer example of a mapping between PCN in IP and in MPLS
using the PCN terminology and concepts that have since been
specified.
To support PCN in a MPLS domain, codepoints for all used PCN-marks
need to be provided in the TC field. That means, when e.g. only
excess-traffic-marking is used for PCN purposes, the operator needs
to define a site-local mapping to codepoints in the MPLS TC field for
IP headers with:
o DSCP n and ECT(0)
o DSCP n and CE
If both excess-traffic-marking and threshold-marking are used, 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:
o DSCP n and ECT(0)
o DSCP n and ECT(1)
o DSCP n and CE
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
site-local mapping to an MPLS TC codepoint for IP headers marked
with:
o DSCP n and Not-ECT
Appendix D. Rationale for different behaviours for single marking
schemes
Readers may notice an apparent discrepancy between the two single
marking behaviours in Section 5.2.3.1 and Section 5.2.3.2. For the
excess-traffic only marking an unexpected ThM marked packet is
remarked as ETM. For the threshold only marking, an unexpected ETM
marked packet is simply ignored (apart from an optional management
alarm).
There are two reasons for having these seemingly contradictory
requirements. Firstly these behaviours conform with the expected
behaviour where both metering functions are being used for marking--
ETM is always a more severe marking than ThM and so should never be
re-marked. Secondly the threshold-metering behaviour in [RFC5670]
uses the current marking state of the arriving packet to determine
what action to take. Consequently, in the ETM only marking it would
be potentially unsafe to allow ThM packets to propagate forward in
the network as they may adversely affect the threshold-metering
function.
Authors' Addresses Authors' Addresses
Bob Briscoe Bob Briscoe
BT BT
B54/77, Adastral Park B54/77, Adastral Park
Martlesham Heath Martlesham Heath
Ipswich IP5 3RE Ipswich IP5 3RE
UK UK
 End of changes. 90 change blocks. 
317 lines changed or deleted 601 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/