< draft-ietf-pcn-3-in-1-encoding-06a.txt   draft-ietf-pcn-3-in-1-encoding-06c.txt >
Congestion and Pre-Congestion B. Briscoe Congestion and Pre-Congestion B. Briscoe
Notification BT Notification BT
Internet-Draft T. Moncaster Internet-Draft T. Moncaster
Obsoletes: 5696 (if approved) Moncaster Internet Consulting Obsoletes: 5696 (if approved) Moncaster Internet Consulting
Intended status: Standards Track M. Menth Intended status: Standards Track M. Menth
Expires: January 4, 2012 University of Tuebingen Expires: January 8, 2012 University of Tuebingen
July 3, 2011 July 7, 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-06 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.
The overall rate of the PCN-traffic is metered on every link in the The overall rate of the PCN-traffic is metered on every link in the
PCN domain, and PCN-packets are appropriately marked when certain PCN domain, and PCN-packets are appropriately marked when certain
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 January 4, 2012. This Internet-Draft will expire on January 8, 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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Changes in This Version (to be removed by RFC Editor) . . 5 1.2. Changes in This Version (to be removed by RFC Editor) . . 5
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 7 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 7
3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 8 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 8
4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 8 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 8
4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 8 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 9
4.2. Requirements imposed by tunnelling . . . . . . . . . . . . 9 4.2. Requirements imposed by tunnelling . . . . . . . . . . . . 9
4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 9 4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 9
5. Behaviour of a PCN-node Compliant with the 3-in-1 PCN 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Common behaviour of PCN-ingress nodes . . . . . . . . . . 10 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 10
5.2. PCN-interior node behaviour . . . . . . . . . . . . . . . 10 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 11
5.2.1. Behaviour common to all compliant PCN-interior 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11
nodes . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.2. Behaviour of PCN-interior Nodes using Two
5.2.2. Behaviour of PCN-interior nodes using one PCN-markings . . . . . . . . . . . . . . . . . . . . . 11
PCN-marking . . . . . . . . . . . . . . . . . . . . . 10 5.2.3. Behaviour of PCN-interior Nodes using One
5.3. Compliant behaviour of PCN-egress nodes . . . . . . . . . 11 PCN-marking . . . . . . . . . . . . . . . . . . . . . 11
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11 5.3. Behaviour of PCN-egress Nodes . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 12
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Backward Compatibility with the Baseline Encoding . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 15 Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 16
Appendix B. Co-existence of ECN and PCN (informative) . . . . . . 16 Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 17
Appendix C. Recommendations for the Use of PCN Encoding Appendix C. Example Mapping between Encoding of PCN-Marks in
Schemes . . . . . . . . . . . . . . . . . . . . . . . 18 IP and in MPLS Shim Headers . . . . . . . . . . . . . 20
C.1. Use of Both Excess-Traffic-Marking and Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Threshold-Marking . . . . . . . . . . . . . . . . . . . . 19
C.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . . . 19
C.3. Unique Use of Threshold-Marking . . . . . . . . . . . . . 19
Appendix D. Example Mapping between Encoding of PCN-Marks in
IP and in MPLS Shim Headers . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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,
skipping to change at page 4, line 37 skipping to change at page 4, line 37
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 which then decide whether to
admit new flows or terminate existing flows admit new flows or terminate existing flows
[I-D.ietf-pcn-cl-edge-behaviour], [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] described how two PCN The baseline encoding defined in [RFC5696] described how two PCN
marking states (Not-marked and PCN-Marked) could be encoded into the marking states (Not-marked and PCN-Marked) could be encoded into the
IP header using a single Diffserv codepoint. It also provided an IP header using a single Diffserv codepoint. It also provided an
experimental codepoint (EXP), along with guidelines for the use of experimental codepoint (EXP), along with guidelines for the use of
that codepoint. Two PCN marking states are sufficient for the Single that codepoint. Two PCN marking states are sufficient for the Single
Marking edge behaviour [I-D.ietf-pcn-sm-edge-behaviour], but PCN- Marking edge behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However,
domains utilising the controlled load edge behaviour PCN-domains utilising the controlled load edge behaviour
[I-D.ietf-pcn-cl-edge-behaviour], require three PCN marking states. [I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states.
This document extends the baseline encoding by redefining the EXP This document extends the baseline encoding by redefining the EXP
codepoint to provide a third PCN marking state in the IP header, codepoint to provide a third PCN marking state in the IP header,
still using a single Diffserv codepoint. As it is inadvisable to still using a single Diffserv codepoint. This encoding scheme is
have two standards actions defining one codepoint in a single therefore called the "3-in-1 PCN encoding". It obsoletes the
context, this document obsoletes the baseline encoding [RFC5696]. baseline encoding [RFC5696], which provides only a sub-set of the
This encoding scheme is called the "3-in-1 PCN encoding". same capabilities.
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
recommendations concerning algorithms for congestion marking or recommendations concerning algorithms for congestion marking or
congestion response. Other documents will define the PCN wire congestion response. Other documents will define the PCN wire
protocol for other header types. Appendix D 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) 1.2. Changes in This Version (to be removed by RFC Editor)
From draft-ietf-pcn-3-in-1-encoding-05 to -06: From draft-ietf-pcn-3-in-1-encoding-05 to -06:
* Draft re-written to obsolete baseline encoding [RFC5696]. * Draft re-written to obsolete baseline encoding [RFC5696].
* New section defining utilising this encoding for single * New section defining utilising this encoding for single
marking. marking.
* Moved informative appendixes from [RFC5696] to this document. * Moved informative appendixes (except the original Appendix C
that is now redundant) from [RFC5696] to this document.
* Significant re-structuring of document. * 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 B discussing ECN handling in the PCN-domain. * Added Appendix B discussing ECN handling in the PCN-domain.
skipping to change at page 6, line 45 skipping to change at page 6, line 45
* References updated. * References updated.
* Terminology brought into line with [RFC5670]. * Terminology brought into line with [RFC5670].
* Minor corrections. * Minor corrections.
2. Definitions and Abbreviations 2. Definitions and Abbreviations
2.1. Terminology 2.1. Terminology
The terms PCN-capable, PCN-domain, PCN-node, PCN-interior-node, PCN- The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node,
ingress-node, PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN- PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and PCN-
packets and PCN-marking are used as defined in [RFC5559]. The marking are used as defined in [RFC5559]. The following additional
following additional terms are defined in this document: 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 is used to carry PCN-markings packets for which the ECN field is used to carry PCN-markings
rather than [RFC3168] markings. rather than [RFC3168] markings (see Appendix A).
Threshold-marked codepoint a codepoint that indicates packets that Threshold-marked codepoint a codepoint that indicates packets that
have been marked at a PCN-interior-node as a result of an have been marked at a PCN-interior-node as a result of an
indication from the threshold-metering function [RFC5670]. indication from the threshold-metering function [RFC5670].
Abbreviated to ThM. Abbreviated to ThM.
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.
Not-marked codepoint a codepoint that indicates packets that are Not-marked codepoint a codepoint that indicates PCN-packets but that
PCN-capable but that are not PCN-marked. Abbreviated to NM. are not PCN-marked. Abbreviated to NM.
not-PCN codepoint a codepoint that indicates packets that are not not-PCN codepoint a codepoint that indicates packets that are not
PCN-capable. 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]
o CE = Congestion Experienced [RFC3168] o CE = Congestion Experienced [RFC3168]
o CS = Class Selector [RFC2474] o CS = Class Selector [RFC2474]
skipping to change at page 8, line 16 skipping to change at page 8, line 16
o PCN = Pre-Congestion Notification o PCN = Pre-Congestion Notification
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 allows for two or three PCN-marking 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 states to be encoded within the IP header. The full encoding is
shown in Figure 1. 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
As mentioned above, the 3-in-1 PCN encoding is an extension of the As mentioned above, the 3-in-1 PCN encoding is an extension of the
baseline encoding [RFC5696]. Like the baseline encoding it uses a baseline encoding [RFC5696]. Like the baseline encoding it uses a
combination of a PCN-compatible DSCP, DSCP n and the ECN field for combination of a PCN-compatible DSCP (DSCP n in Figure 1) and the ECN
the encoding of PCN-marks. The PCN-marks have the following meaning. 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 Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not
subject to PCN metering and marking. 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].
skipping to change at page 8, line 45 skipping to change at page 9, line 4
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 -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.
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. This RFC removes some of the ECN markings within IP-in-IP tunnels. The publication of RFC6040
constraints that existed when [RFC5696] was written (see section removed the tunnelling constraints that existed when the baseline
3.3.2 of [I-D.ietf-pcn-encoding-comparison]). This docuemnt has been encoding [RFC5696] was written (see section 3.3.2 of
written on the assumption that any tunnels will follow the normal [I-D.ietf-pcn-encoding-comparison]).
mode encapsulation rules as defined in [RFC6040].
Nonetheless, there is still a problem if there are any legacy (pre-
RFC6040) decapsulating tunnel endpoints within a PCN domain. If a
PCN node Threshold-marks the outer header of a tunnelled packet, 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.
4.3. Applicability of 3-in-1 PCN Encoding 4.3. Applicability of 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
schemes are being used in the PCN-domain. In some circumstances it behaviours are being used in the PCN-domain. The 3-in-1 encoding can
can also be used in PCN-domains with only a single marking scheme in also be used with only one marking behaviour, in which case one of
use. Further guidance on choosing an encoding scheme can be found in the codepoints MUST NOT be used throughout the PCN-domain (see
Appendix C. All nodes within the PCN-domain MUST be fully compliant Section 5.2.3).
with the ECN encapsulation rules set out in [RFC6040]. As such the
encoding is not applicable in situations where legacy tunnels might
exist. However, in such circumstances a limited version of the
encoding using only excess-traffic-metering would be safe--see
Section 5.2.2.1.
5. Behaviour of a PCN-node Compliant with the 3-in-1 PCN Encoding For the 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP and
IPsec) within the PCN-domain MUST comply with the ECN encapsulation
and decapsulation rules set out in [RFC6040] (see Section 4.2).
There is one exception to this rule outlined next.
As mentioned in Section 4.3 above, all PCN-nodes MUST be compliant If it is not possible to upgrade all pre-RFC6040 tunnel endpoints
with the [RFC6040] normal mode of tunneling. within a PCN domain, the 3-in-1 encoding can still be applicable, but
only under the following stringent condition. If a pre-RFC6040
tunnel endpoint is present anywhere in a PCN-domain, 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 situation where legacy
tunnel endpoints might be present within the PCN domain, the 3-in-1
encoding is not applicable.
5.1. Common behaviour of PCN-ingress nodes 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding
As mentioned in Section 4.3 above, all PCN-nodes MUST comply with
[RFC6040].
5.1. PCN-ingress Node Behaviour
PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint. PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint.
To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are
already defined for use with admission-controlled traffic. already defined for use with admission-controlled traffic.
Appendix A gives guidance to implementors on suitable DSCPs. Appendix A gives guidance to implementors on suitable DSCPs.
Guidelines for mixing traffic types within a PCN-domain are given in Guidelines for mixing traffic types within a PCN-domain are given in
[RFC5670]. [RFC5670].
Any packet arriving at the PCN-ingress-node that shares a PCN- If a packet arrives at the PCN-ingress-node that shares a PCN-
compatible DSCP and is not a PCN-packet MUST be marked as not-PCN compatible DSCP and is not a PCN-packet, the PCN-ingress MUST mark it
within the PCN-domain. as not-PCN.
If a packet arrives at the PCN-ingress-node with its ECN field If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress MUST
change the PCN codepoint to Not-marked.
If a PCN-packet arrives at the PCN-ingress-node with its ECN field
already set to a value other than not-ECT, then appropriate action already set to a value other than not-ECT, then appropriate action
MUST be taken to meet the requirements of [RFC3168]. The simplest MUST be taken to meet the requirements of [RFC4774]. The simplest
appropriate action is to just drop such packets. However, this is a appropriate action is to just drop such packets. However, this is a
drastic action that an operator may feel is undesirable. Appendix B drastic action that an operator may feel is undesirable. Appendix B
provides more information and summarises other alternative actions provides more information and summarises other alternative actions
that might be taken. that might be taken.
5.2. PCN-interior node behaviour 5.2. PCN-interior Node Behaviour
5.2.1. Behaviour common to all compliant PCN-interior nodes
PCN-interior nodes MUST NOT change not-PCN packets to any other type 5.2.1. Behaviour Common to all PCN-interior Nodes
of packet.
PCN-interior nodes MUST NOT mark any packets with the not-PCN Interior nodes MUST NOT change not-PCN to any other codepoint.
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 one PCN-marking 5.2.2. Behaviour of PCN-interior Nodes using Two PCN-markings
If the threshold-meter function indicates a need to mark the packet,
the PCN-interior node MUST change NM to ThM.
If the excess-traffic-meter function indicates a need to mark the
packet:
o the PCN-interior node MUST change NM to ETM;
o the PCN-interior node MUST change ThM to ETM.
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.
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
[I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark [I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark
packets using the excess-traffic-meter function [RFC5670], but future packets using the excess-traffic-meter function [RFC5670]. It is
schemes may only require the threshold-meter function. possible that future schemes may require only the threshold-meter
function.
5.2.2.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 MUST change NM to ETM if the excess-traffic- The PCN-interior node SHOULD raise a management alarm if it receives
meter function indicates a need to mark the packet. a ThM packet, but the frequency of such alarms SHOULD be limited.
The PCN-interior node MUST NOT change ThM to ETM. It SHOULD raise a If the excess-traffic-meter function indicates a need to mark the
management alarm if it receives a ThM packet but the frequency of packet:
such alarms SHOULD be limited.
5.2.2.2. Marking using only the Threshold Meter Function o the PCN-interior node MUST change NM to ETM;
The PCN-interior node MUST change NM to ThM if the threshold-meter o the PCN-interior node MUST change ThM to ETM. It SHOULD also
function indicates a need to mark the packet. raise an alarm as above.
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.
If the PCN-interior node receives an ETM packet it MUST NOT remark The PCN-interior node SHOULD raise a management alarm if it receives
this to ThM, NM or not-PCN. If such a packet is received the PCN- an ETM packet, but the frequency of such alarms SHOULD be limited.
interior node SHOULD raise a management alarm but the frequency of
such alarms SHOULD be limited.
5.3. Compliant behaviour of PCN-egress nodes 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 NOT change ETM to any other codepoint.
It SHOULD raise an alarm as above.
5.3. Behaviour of PCN-egress Nodes
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. The only exception to packets it forwards out of the PCN-domain.
this is if the PCN-egress-node is certain that revealing other
codepoints outside the PCN-domain won't contravene the guidance given The only exception to this is if the PCN-egress-node is certain that
in [RFC4774]. For instance, if the PCN-ingress-node has explicitly revealing other codepoints outside the PCN-domain won't contravene
informed the PCN-egress-node that this flow is ECN-capable, then it the guidance given in [RFC4774]. For instance, if the PCN-ingress-
might be safe to expose other codepoints. Appendix B gives details node has explicitly informed the PCN-egress-node that this flow is
of how such schemes might work, but such schemes are NOT RECOMMENDED. 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 the PCN-domain is configured to only use one PCN-marking, the PCN- If the PCN-domain is configured to only use one PCN-marking, the PCN-
egress node MAY treat ThM as ETM and ETM as ThM. However it SHOULD egress node MUST treat ThM as ETM or ETM as ThM. However it SHOULD
raise a management alarm in this instance since this means there is raise a management alarm in this instance since this means there is
some misconfiguration in the PCN-domain. some misconfiguration in the PCN-domain.
6. Backward Compatibility 6. Backward Compatibility
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 co-existence of default ECN and alternative ECN semantics.
The encoding specified in this document defines PCN-compatible The encoding specified in this document uses one of those techniques;
Diffserv codepoints as no longer supporting the default ECN it defines PCN-compatible Diffserv codepoints as no longer supporting
semantics. As such, this document is compatible with BCP 124. the default ECN semantics. As such, this document is compatible with
BCP 124.
On its own, this encoding cannot support both ECN marking end-to-end On its own, the 3-in-1 encoding cannot support both ECN marking end-
(e2e) and PCN-marking within a PCN-domain. It is possible to do this to-end (e2e) and PCN-marking within a PCN-domain. Appendix B
by carrying e2e ECN across a PCN-domain within the inner header of an discusses possible ways to do this, e.g. by carrying e2e ECN across a
IP-in-IP tunnel, or by using a richer encoding, but such schemes are PCN-domain within the inner header of an IP-in-IP tunnel, or by using
beyond the scope of this document. a richer encoding. 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 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 PCN field in their outermost IP header set to the appropriate PCN
codepoint. PCN-egress-nodes then guarantee that the ECN field of any codepoint. PCN-egress-nodes then guarantee that the ECN field of any
packet leaving the PCN-domain has appropriate ECN semantics. This packet leaving the PCN-domain has appropriate ECN semantics. This
prevents unintended leakage of ECN marks into or out of the PCN- prevents unintended leakage of ECN marks into or out of the PCN-
domain, and thus reduces backward-compatibility issues. 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, there is no reason to believe that such an
implementation would ever have been built.
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
PCN-marking only carries a meaning within the confines of a PCN- PCN-marking only carries a meaning within the confines of a PCN-
skipping to change at page 13, line 6 skipping to change at page 14, line 15
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 behaviour schemes is used, but in general spurious marks will node behaviours is used, but in general spurious marks will lead to
lead to admitting fewer flows into the domain or potentially admitting fewer flows into the domain or potentially terminating too
terminating too many flows. In either case, good management should many flows. In either case, good management should be able to
be able to quickly spot the problem since the overall utilisation of quickly spot the problem since the overall utilisation of the domain
the domain will rapidly fall. 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 tunnel In general, the use of this PCN encoding scheme presupposes that any
endpoints within the PCN-domain have been updated to comply with tunnel endpoints within the PCN-domain have been updated to comply
[RFC6040]. with [RFC6040].
10. Acknowledgements 10. Acknowledgements
Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan, Ruediger Geib and Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan, Ruediger Geib and
Georgios Karaginannis for reviewing this document. Georgios Karaginannis for reviewing this 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
skipping to change at page 13, line 46 skipping to change at page 15, line 10
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[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.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009.
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
Nodes", RFC 5670, November 2009.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010.
12.2. Informative References
[I-D.ietf-pcn-cl-edge-behaviour]
Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
Taylor, "PCN Boundary Node Behaviour for the Controlled
Load (CL) Mode of Operation",
draft-ietf-pcn-cl-edge-behaviour-09 (work in progress),
June 2011.
[I-D.ietf-pcn-encoding-comparison]
Karagiannis, G., Chan, K., Moncaster, T., Menth, M.,
Eardley, P., and B. Briscoe, "Overview of Pre-Congestion
Notification Encoding",
draft-ietf-pcn-encoding-comparison-06 (work in progress),
June 2011.
[I-D.ietf-pcn-sm-edge-behaviour]
Charny, A., Karagiannis, G., Menth, M., and T. Taylor,
"PCN Boundary Node Behaviour for the Single Marking (SM)
Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-06
(work in progress), June 2011.
[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, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002. Behavior)", RFC 3246, March 2002.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003. 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 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
August 2006. August 2006.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the [RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124, Explicit Congestion Notification (ECN) Field", BCP 124,
RFC 4774, November 2006. RFC 4774, November 2006.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
DiffServ Service Classes", RFC 5127, February 2008. DiffServ Service Classes", RFC 5127, February 2008.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008. Marking in MPLS", RFC 5129, January 2008.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009. Class" Field", RFC 5462, February 2009.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009.
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
Nodes", RFC 5670, November 2009.
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information", Encoding and Transport of Pre-Congestion Information",
RFC 5696, November 2009. RFC 5696, November 2009.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic", Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, May 2010. RFC 5865, May 2010.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010.
12.2. Informative References
[I-D.ietf-pcn-cl-edge-behaviour]
Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
Taylor, "PCN Boundary Node Behaviour for the Controlled
Load (CL) Mode of Operation",
draft-ietf-pcn-cl-edge-behaviour-09 (work in progress),
June 2011.
[I-D.ietf-pcn-encoding-comparison]
Karagiannis, G., Chan, K., Moncaster, T., Menth, M.,
Eardley, P., and B. Briscoe, "Overview of Pre-Congestion
Notification Encoding",
draft-ietf-pcn-encoding-comparison-06 (work in progress),
June 2011.
[I-D.ietf-pcn-sm-edge-behaviour]
Charny, A., Karagiannis, G., Menth, M., and T. Taylor,
"PCN Boundary Node Behaviour for the Single Marking (SM)
Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-06
(work in progress), June 2011.
Appendix A. Choice of Suitable DSCPs 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 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 PCN for several reasons. Firstly, the PCN mechanism is applicable to
a variety of different traffic classes. Secondly, Standards Track a variety of different traffic classes. Secondly, Standards Track
DSCPs are in increasingly short supply. Thirdly, PCN is not a DSCPs are in increasingly short supply. Thirdly, PCN is not a
scheduling behaviour -- rather, it should be seen as being a marking scheduling behaviour -- rather, it should be seen as being a marking
behaviour similar to ECN but intended for inelastic traffic. The behaviour similar to ECN but intended for inelastic traffic. The
choice of which DSCP is most suitable for a given PCN-domain is 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 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 link rates of all the links making up that domain. In PCN-domains
with sufficient aggregation, the appropriate DSCPs would currently be with sufficient aggregation, the appropriate DSCPs would currently be
skipping to change at page 16, line 32 skipping to change at page 17, line 39
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 (informative) 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 The following lists the four cases for how e2e
ECN traffic may wish to be treated while crossing a PCN domain: 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 18, line 8 skipping to change at page 19, line 14
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 where the e2e transport somehow
indicates that it wants to see PCN marks: NOTE this is currently indicates that it wants to see PCN marks: NOTE this is currently
experimental only. 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]. The PCN-egress should not zero the ECN field, and
should use [RFC6040] normal mode (preserving any PCN-marking). the [RFC6040] tunnel egress will preserve any PCN-marking. Note
Note that this may turn ECT(0) into ECT(1) and so is not that a PCN interior node may turn ECT(0) into ECT(1), which would
compatible with the experimental ECN nonce [RFC3540]. 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 Unless specified otherwise, for any of the cases in the list above an
specified otherwise. NB, We assume a logical separation of tunneling IP-in-IP tunnel can be used to preserve ECN markings across the PCN
and PCN actions in both PCN-ingress and PCN-egress nodes. That is, domain. The tunnelling action should be applied wholly outside the
any tunneling action happens wholly outside the PCN-domain as PCN-domain as illustrated in the following figure:
illustrated in the following figure:
, . . . . . 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 tunneling and PCN actions Figure 2: Separation of tunneling and PCN actions
Appendix C. Recommendations for the Use of PCN Encoding Schemes Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in
NOTE: This appendix is informative not normative.
When deciding which PCN encoding is suitable an operator needs to
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.
+------------------------+--------------------------------+
| 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
C.1. Use of Both Excess-Traffic-Marking and Threshold-Marking
If both excess-traffic-marking and threshold-marking are enabled in a
PCN-domain, 3-in-1 encoding should be used as described in this
document.
C.2. Unique Use of Excess-Traffic-Marking
If only excess-traffic-marking is enabled in a PCN-domain, baseline
encoding or 3-in-1 encoding may be used. They lead to the same
encoding because PCN-boundary nodes will interpret baseline "PCN-
marked (PM)" as "excess-traffic-marked (ETM)".
C.3. Unique Use of Threshold-Marking
No scheme is currently proposed that solely uses threshold-marking.
If such a scheme is proposed, the choice of encoding scheme will
depend on whether nodes are compliant with [RFC6040] or not. Where
it is certain that all nodes in the PCN-domain are compliant then
either 3-in-1 encoding or baseline encoding are suitable. If legacy
tunnel decapsulators exist within the PCN-domain then baseline
encoding SHOULD be used.
Appendix D. 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 8 bits of the DS field in the IP header provide for 256 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 bits traffic class (TC) However, the MPLS shim header has only a 3-bit traffic class (TC)
field [RFC5462] providing for 8 codepoints. The operator has the field [RFC5462] providing for 8 codepoints. The operator has the
freedom to define a site-local mapping of a subset of the 256 freedom to define a site-local mapping of a subset of the 64
codepoints of the DS to the 8 codepoints in the TC field. codepoints of the DS field to the 8 codepoints in the TC field.
[RFC5129] describes how ECN markings in the IP header can be mapped [RFC5129] describes how ECN markings in the IP header can also be
to codepoints in the MPLS TC field. Appendix A of [RFC5129] gives an mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129]
informative description of how to extend the ECN approach for MPLS to gives an informative description of how to support PCN in MPLS by
PCN marking in MPLS. But [RFC5129] was written while PCN extending the way MPLS supports ECN. But [RFC5129] was written while
specifications were in early draft stages. The following provides a PCN specifications were in early draft stages. The following
clearer example of a mapping between PCN in IP and in MPLS using the provides a clearer example of a mapping between PCN in IP and in MPLS
PCN terminology and concepts that have since been specified. using the PCN terminology and concepts that have since been
specified.
To support PCN in a MPLS domain, codepoints for all used PCN-marks To support PCN in a MPLS domain, codepoints for all used PCN-marks
need to be provided in the TC field. That means, when only excess- need to be provided in the TC field. That means, when e.g. only
traffic-marking or only threshold-marking is used for PCN purposes, excess-traffic-marking is used for PCN purposes, the operator needs
the operator needs to define a site-local mapping to codepoints in to define a site-local mapping to codepoints in the MPLS TC field for
the MPLS TC field for IP headers with: IP headers with:
o DSCP n and ECT(0) o DSCP n and ECT(0)
o DSCP n and CE o DSCP n and CE
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 the 3-in-1 encoding of the present MPLS TC field for IP headers with all three of the 3-in-1 codepoints:
document:
o DSCP n and ECT(0) o DSCP n and ECT(0)
o DSCP n and ECT(1) o DSCP n and ECT(1)
o DSCP n and CE o DSCP n and CE
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
 End of changes. 74 change blocks. 
264 lines changed or deleted 271 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/