draft-ietf-pcn-3-in-1-encoding-07.txt | draft-ietf-pcn-3-in-1-encoding-08.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 31, 2012 University of Tuebingen | Expires: February 19, 2012 University of Tuebingen | |||
July 30, 2011 | August 18, 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-07 | draft-ietf-pcn-3-in-1-encoding-08 | |||
Abstract | Abstract | |||
The objective of Pre-Congestion Notification (PCN) is to protect the | The objective of Pre-Congestion Notification (PCN) is to protect the | |||
quality of service (QoS) of inelastic flows within a Diffserv domain. | quality of service (QoS) of inelastic flows within a Diffserv domain. | |||
The overall rate of the PCN-traffic is metered on every link in the | The overall rate of the PCN-traffic is metered on every link in the | |||
PCN domain, and PCN-packets are appropriately marked when certain | PCN domain, and PCN-packets are appropriately marked when certain | |||
configured rates are exceeded. Egress nodes pass information about | configured rates are exceeded. Egress nodes pass information about | |||
these PCN-marks to decision points which then decide whether to admit | these PCN-marks to decision points which then decide whether to admit | |||
or block new flow requests or to terminate some already-admitted | or block new flow requests or to terminate some already-admitted | |||
flows during serious pre-congestion. | flows during serious pre-congestion. | |||
This document specifies how PCN-marks are to be encoded into the IP | This document specifies how PCN-marks are to be encoded into the IP | |||
header by re-using the Explicit Congestion Notification (ECN) | header by re-using the Explicit Congestion Notification (ECN) | |||
codepoints within a PCN-domain. This encoding provides for up to | codepoints within a PCN-domain. This encoding provides for up to | |||
three different PCN marking states using a single DSCP: not-marked | three different PCN marking states using a single DSCP: not-marked | |||
(NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, | (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, | |||
it is called the 3-in-1 PCN encoding. This document obsoletes | it is called the 3-in-1 PCN encoding. This document obsoletes | |||
RFC5696. | 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 January 31, 2012. | This Internet-Draft will expire on February 19, 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 27 | skipping to change at page 3, line 27 | |||
4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 10 | 4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 10 | |||
5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN | 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN | |||
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 11 | 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 11 | |||
5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 11 | 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 11 | |||
5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11 | 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11 | |||
5.2.2. Behaviour of PCN-interior Nodes Using Two | 5.2.2. Behaviour of PCN-interior Nodes Using Two | |||
PCN-markings . . . . . . . . . . . . . . . . . . . . . 12 | PCN-markings . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.2.3. Behaviour of PCN-interior Nodes Using One | 5.2.3. Behaviour of PCN-interior Nodes Using One | |||
PCN-marking . . . . . . . . . . . . . . . . . . . . . 12 | PCN-marking . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.3. Behaviour of PCN-egress Nodes . . . . . . . . . . . . . . 13 | 5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 13 | |||
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13 | 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13 | |||
6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13 | 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13 | |||
6.2. Backward Compatibility with the Baseline Encoding . . . . 14 | 6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 14 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15 | 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . . 16 | 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 | |||
Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 17 | Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 18 | |||
Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 18 | Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 19 | |||
Appendix C. Example Mapping between Encoding of PCN-Marks in | Appendix C. Example Mapping between Encoding of PCN-Marks in | |||
IP and in MPLS Shim Headers . . . . . . . . . . . . . 20 | IP and in MPLS Shim Headers . . . . . . . . . . . . . 21 | |||
Appendix D. Rationale for Discrepancy Between the Schemes | Appendix D. Rationale for Difference Between the Schemes | |||
using One PCN-Marking . . . . . . . . . . . . . . . . 22 | using One PCN-Marking . . . . . . . . . . . . . . . . 22 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
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 32 | skipping to change at page 4, line 32 | |||
marking marks all PCN packets once their traffic rate on a link | marking marks all PCN packets once their traffic rate on a link | |||
exceeds the configured reference rate (PCN-threshold-rate). Excess- | exceeds the configured reference rate (PCN-threshold-rate). Excess- | |||
traffic-marking marks only those PCN packets that exceed the | traffic-marking marks only those PCN packets that exceed the | |||
configured reference rate (PCN-excess-rate). The PCN-excess-rate is | configured reference rate (PCN-excess-rate). The PCN-excess-rate is | |||
typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes | typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes | |||
monitor the PCN-marks of received PCN-packets and pass information | monitor the PCN-marks of received PCN-packets and pass information | |||
about these PCN-marks to decision points which then decide whether to | about these PCN-marks to decision points 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 encoding defined in [RFC5696] described how two PCN marking | |||
marking states (Not-marked and PCN-Marked) could be encoded into the | states (Not-marked and PCN-Marked) could be encoded into the IP | |||
IP header using a single Diffserv codepoint. It also provided an | header using a single Diffserv codepoint. It defined 01 as an | |||
experimental codepoint (EXP), along with guidelines for the use of | experimental codepoint (EXP), along with guidelines for its use. Two | |||
that codepoint. Two PCN marking states are sufficient for the Single | PCN marking states are sufficient for the Single Marking edge | |||
Marking edge behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However, | behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However, PCN-domains | |||
PCN-domains utilising the controlled load edge behaviour | 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 RFC5696 encoding by redefining the | |||
codepoint to provide a third PCN marking state in the IP header, | experimental codepoint as a third PCN marking state in the IP header, | |||
still using a single Diffserv codepoint. This encoding scheme is | still using a single Diffserv codepoint. This encoding scheme is | |||
therefore called the "3-in-1 PCN encoding". It obsoletes the | therefore called the "3-in-1 PCN encoding". It obsoletes the | |||
baseline encoding [RFC5696], which provides only a sub-set of the | [RFC5696] encoding, which provides only a sub-set of the same | |||
same capabilities. | capabilities. | |||
The full version of this encoding requires any tunnel endpoint within | The full version of this encoding requires any tunnel endpoint within | |||
the PCN-domain to support the normal tunnelling rules defined in | the PCN-domain to support the normal tunnelling rules defined in | |||
[RFC6040]. There is one limited exception to this constraint where | [RFC6040]. There is one limited exception to this constraint where | |||
the PCN-domain only uses the excess-traffic-marking behaviour and | the PCN-domain only uses the excess-traffic-marking behaviour and | |||
where the threshold-marking behaviour is deactivated. This is | where the threshold-marking behaviour is deactivated. This is | |||
discussed in Section 5.2.3.1. | discussed in Section 5.2.3.1. | |||
This document only concerns the PCN wire protocol encoding for IP | This document only concerns the PCN wire protocol encoding for IP | |||
headers, whether IPv4 or IPv6. It makes no changes or | headers, whether IPv4 or IPv6. It makes no changes or | |||
skipping to change at page 5, line 20 | skipping to change at page 5, line 20 | |||
mapping between IP and MPLS. | mapping between IP and MPLS. | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
1.2. Changes in This Version (to be removed by RFC Editor) | 1.2. Changes in This Version (to be removed by RFC Editor) | |||
From draft-ietf-pcn-3-in-1-encoding-07 to -08: Editorial corrections | ||||
and clarifications. | ||||
From draft-ietf-pcn-3-in-1-encoding-06 to -07: | From draft-ietf-pcn-3-in-1-encoding-06 to -07: | |||
* Clarified that each operator not the IETF chooses which DSCP(s) | * Clarified that each operator not the IETF chooses which DSCP(s) | |||
are PCN-compatible, and made it unambiguous that only PCN-nodes | are PCN-compatible, and made it unambiguous that only PCN-nodes | |||
recognise that PCN-compatible DSCPs enable the 3-in-1 encoding. | recognise that PCN-compatible DSCPs enable the 3-in-1 encoding. | |||
* Removed statements about the PCN working group, given RFCs are | * Removed statements about the PCN working group, given RFCs are | |||
meant to survive beyond the life of a w-g. | meant to survive beyond the life of a w-g. | |||
* Corrected the final para of "Rationale for Different Behaviours | * Corrected the final para of "Rationale for Different Behaviours | |||
skipping to change at page 7, line 32 | skipping to change at page 7, line 39 | |||
PCN encoding: mapping of PCN marking states to specific codepoints | PCN encoding: mapping of PCN marking states to specific codepoints | |||
in the packet header. | in the packet header. | |||
PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating | PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating | |||
packets for which the ECN field carries PCN-markings rather than | packets for which the ECN field carries PCN-markings rather than | |||
[RFC3168] markings. Note that an operator configures PCN-nodes to | [RFC3168] markings. Note that an operator configures PCN-nodes to | |||
recognise PCN-compatible DSCPs, whereas the same DSCP has no PCN- | recognise PCN-compatible DSCPs, whereas the same DSCP has no PCN- | |||
specific meaning to a node outside the PCN domain. | specific meaning to a node outside the PCN domain. | |||
Threshold-marked codepoint: a codepoint that indicates packets that | Threshold-marked codepoint: a codepoint that indicates a packet has | |||
have been marked at a PCN-interior-node as a result of an | been threshold-marked; that is a packet that has been marked at a | |||
indication from the threshold-metering function [RFC5670]. | PCN-interior-node as a result of an indication from the threshold- | |||
Abbreviated to ThM. | metering function [RFC5670]. 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 PCN-packets but | Not-marked codepoint: a codepoint that indicates PCN-packets that | |||
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-packets. | PCN-packets. | |||
2.2. List of Abbreviations | 2.2. List of Abbreviations | |||
The following abbreviations are used in this document: | The following abbreviations are used in this document: | |||
o AF = Assured Forwarding [RFC2597] | o AF = Assured Forwarding [RFC2597] | |||
skipping to change at page 8, line 49 | skipping to change at page 9, line 4 | |||
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 | |||
A PCN-node (i.e. a node within a PCN-domain) will be configured to | A PCN-node (i.e. a node within a PCN-domain) will be configured to | |||
recognise certain DSCPs as PCN-compatible. Appendix A discusses the | recognise certain DSCPs as PCN-compatible. Appendix A discusses the | |||
choice of suitable DSCPs. In Figure 1 'DSCP n' indicates such a PCN- | choice of suitable DSCPs. In Figure 1 'DSCP n' indicates such a PCN- | |||
compatible DSCP. Within the PCN-domain, any packet carrying a PCN- | compatible DSCP. Within the PCN-domain, any packet carrying a PCN- | |||
compatible DSCP is a PCN-packet as defined in [RFC5559]. | compatible DSCP and with the ECN-field anything other than 00 (Not- | |||
PCN) is a PCN-packet as defined in [RFC5559]. | ||||
PCN-nodes MUST interpret the ECN field of a PCN-packet using the | PCN-nodes MUST interpret the ECN field of a PCN-packet using the | |||
3-in-1 PCN encoding, rather than [RFC3168]. This does not change the | 3-in-1 PCN encoding, rather than [RFC3168]. This does not change the | |||
behaviour for any packet with a DSCP that is not PCN-compatible, or | behaviour for any packet with a DSCP that is not PCN-compatible, or | |||
for any node outside a PCN-domain. In all such cases the 3-in-1 | for any node outside a PCN-domain. In all such cases the 3-in-1 | |||
encoding is not applicable and so by default the node will interpret | encoding is not applicable and so by default the node will interpret | |||
the ECN field using [RFC3168]. | the ECN field using [RFC3168]. | |||
When using the 3-in-1 encoding, the codepoints of the ECN field have | When using the 3-in-1 encoding, the codepoints of the ECN field have | |||
the following meanings: | the following meanings: | |||
skipping to change at page 10, line 21 | skipping to change at page 10, line 23 | |||
In all current PCN edge behaviors that use two marking behaviours | 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. The publication of RFC6040 | ECN markings within IP-in-IP tunnels. The publication of RFC6040 | |||
removed the tunnelling constraints that existed when the baseline | removed the tunnelling constraints that existed when the encoding of | |||
encoding [RFC5696] was written (see section 3.3.2 of | [RFC5696] was written (see section 3.3.2 of | |||
[I-D.ietf-pcn-encoding-comparison]). | [I-D.ietf-pcn-encoding-comparison]). | |||
Nonetheless, there is still a problem if there are any legacy (pre- | Nonetheless, there is still a problem if there are any legacy (pre- | |||
RFC6040) decapsulating tunnel endpoints within a PCN domain. If a | RFC6040) decapsulating tunnel endpoints within a PCN domain. If a | |||
PCN node Threshold-marks the outer header of a tunnelled packet with | PCN node Threshold-marks the outer header of a tunnelled packet that | |||
a Not-marked codepoint on the inner header, the legacy decapsulator | has a Not-marked codepoint on the inner header, a legacy decapsulator | |||
will revert the Threshold-marking to Not-marked. The rules on | will forward the packet as Not-marked, losing the threshold marking. | |||
applicability in Section 4.3 below are designed to avoid this | The rules on applicability in Section 4.3 below are designed to avoid | |||
problem. | 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 | |||
behaviours are being used in the PCN-domain. The 3-in-1 encoding can | behaviours are being used in the PCN-domain. The 3-in-1 encoding can | |||
also be used with only one marking behaviour, in which case one of | also be used with only one marking behaviour, in which case one of | |||
the codepoints MUST NOT be used throughout the PCN-domain (see | the codepoints MUST NOT be used throughout the PCN-domain (see | |||
Section 5.2.3). | Section 5.2.3). | |||
For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP | With one exception (see next paragraph), any tunnel endpoints | |||
and IPsec) within the PCN-domain MUST comply with the ECN | (IP-in-IP and IPsec) within the PCN-domain MUST comply with the ECN | |||
encapsulation and decapsulation rules set out in [RFC6040] (see | encapsulation and decapsulation rules set out in [RFC6040] (see | |||
Section 4.2). There is one exception to this rule outlined next. | Section 4.2). | |||
It may not be possible to upgrade every pre-RFC6040 tunnel endpoint | It may not be possible to upgrade every pre-RFC6040 tunnel endpoint | |||
within a PCN-domain. In such circumstances a limited version of the | within a PCN-domain. In such circumstances a limited version of the | |||
3-in-1 encoding can still be used but only under the following | 3-in-1 encoding can still be used but only under the following | |||
stringent condition. If any pre-RFC6040 tunnel endpoint exists | stringent condition. If any pre-RFC6040 tunnel endpoint exists | |||
within a PCN-domain then every PCN-node in the PCN-domain MUST be | 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 | configured so that it never sets the ThM codepoint. PCN-interior | |||
PCN-interior nodes in this case is defined in Section 5.2.3.1, which | nodes in this case MUST solely use the Excess Traffic marking | |||
describes the rules for using only the Excess Traffic marking | function, as defined in Section 5.2.3.1. In all other situations | |||
function. In all other situations where legacy tunnel endpoints | where legacy tunnel endpoints might be present within the PCN domain, | |||
might be present within the PCN domain, the 3-in-1 encoding is not | the 3-in-1 encoding is not applicable. | |||
applicable. | ||||
5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding | 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding | |||
As mentioned in Section 4.3 above, all PCN-nodes MUST comply with | Any tunnel endpoint implementation on a PCN-node MUST comply with | |||
[RFC6040]. | [RFC6040]. Since PCN is a new capability, this is considered a | |||
reasonable requirement. | ||||
5.1. PCN-ingress Node Behaviour | 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]. | |||
If a packet arrives 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, the PCN-ingress MUST mark it | compatible DSCP and is not a PCN-packet, the PCN-ingress-node MUST | |||
as not-PCN. | mark it as not-PCN. | |||
If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress MUST | If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress-node | |||
change the PCN codepoint to Not-marked. | MUST change the PCN codepoint to Not-marked. | |||
If a PCN-packet arrives at the PCN-ingress-node with its ECN field | 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 [RFC4774]. 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 | |||
skipping to change at page 12, line 7 | skipping to change at page 12, line 7 | |||
Interior nodes MUST NOT change not-PCN to any other codepoint. | Interior nodes MUST NOT change not-PCN to any other codepoint. | |||
Interior nodes MUST NOT change NM to not-PCN. | Interior nodes MUST NOT change NM to not-PCN. | |||
Interior nodes MUST NOT change ThM to NM or not-PCN. | Interior nodes MUST NOT change ThM to NM or not-PCN. | |||
Interior nodes MUST NOT change ETM to any other codepoint. | Interior nodes MUST NOT change ETM to any other codepoint. | |||
5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings | 5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings | |||
If the threshold-meter function indicates a need to mark the packet, | If the threshold-meter function indicates a need to mark a packet, | |||
the PCN-interior node MUST change NM to ThM. | the PCN-interior node MUST change NM to ThM. | |||
If the excess-traffic-meter function indicates a need to mark the | If the excess-traffic-meter function indicates a need to mark a | |||
packet: | packet: | |||
o the PCN-interior node MUST change NM to ETM; | o the PCN-interior node MUST change NM to ETM; | |||
o the PCN-interior node MUST change ThM to ETM. | o the PCN-interior node MUST change ThM to ETM. | |||
If both the threshold meter and the excess-traffic meter indicate the | If both the threshold meter and the excess-traffic meter indicate the | |||
need to mark a packet, the excess traffic marking rules MUST take | need to mark a packet, the Excess-traffic-marking rules MUST take | |||
priority. | precedence. | |||
5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking | 5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking | |||
Some PCN edge behaviours require only one PCN-marking within the PCN- | Some PCN edge behaviours require only one PCN-marking within the PCN- | |||
domain. The Single Marking edge behaviour | domain. The Single Marking edge behaviour | |||
[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]. It is | packets using the excess-traffic-meter function [RFC5670]. It is | |||
possible that future schemes may require only the threshold-meter | possible that future schemes may require only the threshold-meter | |||
function. Observant readers may spot an apparent inconsistency | function. Appendix D explains the rationale for the behaviours | |||
between the two following cases. Appendix D explains the rationale | defined in this section. | |||
behind this inconsistency. | ||||
5.2.3.1. Marking using only the Excess-traffic-meter Function | 5.2.3.1. Marking Using only the Excess-traffic-meter Function | |||
The threshold-traffic-meter function SHOULD be disabled and MUST NOT | The threshold-traffic-meter function SHOULD be disabled and MUST NOT | |||
trigger any packet marking. | trigger any packet marking. | |||
The PCN-interior node SHOULD raise a management alarm if it receives | The PCN-interior node SHOULD raise a management alarm if it receives | |||
a ThM packet, but the frequency of such alarms SHOULD be limited. | a ThM packet, but the frequency of such alarms SHOULD be limited. | |||
If the excess-traffic-meter function indicates a need to mark the | If the excess-traffic-meter function indicates a need to mark the | |||
packet: | packet: | |||
skipping to change at page 13, line 13 | skipping to change at page 13, line 11 | |||
trigger any packet marking. | trigger any packet marking. | |||
The PCN-interior node SHOULD raise a management alarm if it receives | The PCN-interior node SHOULD raise a management alarm if it receives | |||
an ETM packet, but the frequency of such alarms SHOULD be limited. | an ETM packet, but the frequency of such alarms SHOULD be limited. | |||
If the threshold-meter function indicates a need to mark the packet: | If the threshold-meter function indicates a need to mark the packet: | |||
o the PCN-interior node MUST change NM to ThM; | o the PCN-interior node MUST change NM to ThM; | |||
o the PCN-interior node MUST NOT change ETM to any other codepoint. | o the PCN-interior node MUST NOT change ETM to any other codepoint. | |||
It SHOULD raise an alarm as above. | It SHOULD raise an alarm as above if it encounters an ETM packet. | |||
5.3. Behaviour of PCN-egress Nodes | 5.3. PCN-egress Node Behaviour | |||
A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all | A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all | |||
packets it forwards out of the PCN-domain. | packets it forwards out of the PCN-domain. | |||
The only exception to this is if the PCN-egress-node is certain that | The only exception to this is if the PCN-egress-node is certain that | |||
revealing other codepoints outside the PCN-domain won't contravene | revealing other codepoints outside the PCN-domain won't contravene | |||
the guidance given in [RFC4774]. For instance, if the PCN-ingress- | the guidance given in [RFC4774]. For instance, if the PCN-ingress- | |||
node has explicitly informed the PCN-egress-node that this flow is | node has explicitly informed the PCN-egress-node that this flow is | |||
ECN-capable, then it might be safe to expose other codepoints. | ECN-capable, then it might be safe to expose other codepoints. | |||
Appendix B gives details of how such schemes might work, but such | Appendix B gives details of how such schemes might work, but such | |||
schemes are currently only tentative ideas. | schemes are currently only tentative ideas. | |||
If the PCN-domain is configured to use only excess-traffic marking, | If the PCN-domain is configured to use only excess-traffic marking, | |||
the PCN-egress node MUST treat ThM as ETM and if only threshold- | the PCN-egress node MUST treat ThM as ETM and, if only threshold- | |||
marking is used it should treat ETM as ThM. However it SHOULD raise | marking is used, it SHOULD treat ETM as ThM. However it SHOULD raise | |||
a management alarm in either instance since this means there is some | a management alarm in either instance since this means there is some | |||
misconfiguration in the PCN-domain. | misconfiguration in the PCN-domain. | |||
6. Backward Compatibility | 6. Backward Compatibility | |||
6.1. Backward Compatibility with ECN | 6.1. Backward Compatibility with ECN | |||
BCP 124 [RFC4774] gives guidelines for specifying alternative | BCP 124 [RFC4774] gives guidelines for specifying alternative | |||
semantics for the ECN field. It sets out a number of factors to be | semantics for the ECN field. It sets out a number of factors to be | |||
taken into consideration. It also suggests various techniques to | taken into consideration. It also suggests various techniques to | |||
allow the co-existence of default ECN and alternative ECN semantics. | allow the co-existence of default ECN and alternative ECN semantics. | |||
The encoding specified in this document uses one of those techniques; | The encoding specified in this document uses one of those techniques; | |||
it defines PCN-compatible Diffserv codepoints as no longer supporting | it defines PCN-compatible Diffserv codepoints as no longer supporting | |||
the default ECN semantics. As such, this document is compatible with | the default ECN semantics within a PCN domain. As such, this | |||
BCP 124. | document is compatible with BCP 124. | |||
On its own, the 3-in-1 encoding cannot support both ECN marking end- | 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 | 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 | 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 | PCN-domain within the inner header of an IP-in-IP tunnel. Although | |||
Appendix B recommends various approaches over others, it is merely | Appendix B recommends various approaches over others, it is merely | |||
informative and all such schemes are beyond the normative scope of | informative and all such schemes are beyond the normative scope of | |||
this document. | 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 codepoint. | |||
codepoint. PCN-egress-nodes then guarantee that the ECN field of any | PCN-egress-nodes then guarantee that the ECN field of any packet | |||
packet leaving the PCN-domain has appropriate ECN semantics. This | leaving the PCN-domain has appropriate ECN semantics. This prevents | |||
prevents unintended leakage of ECN marks into or out of the PCN- | unintended leakage of ECN marks into or out of the PCN-domain, and | |||
domain, and thus reduces backward-compatibility issues. | thus reduces backward-compatibility issues. | |||
6.2. Backward Compatibility with the Baseline Encoding | 6.2. Backward Compatibility with the RFC5696 Encoding | |||
A PCN node implemented to use the obsoleted baseline encoding could | A PCN node implemented to use the obsoleted RFC5696 encoding could | |||
conceivably have been configured so that the Threshold-meter function | conceivably have been configured so that the Threshold-meter function | |||
marked what is now defined as the ETM codepoint in the 3-in-1 | marked what is now defined as the ETM codepoint in the 3-in-1 | |||
encoding. However, thre is no known deployment of such an | encoding. However, there is no known deployment of such an | |||
implementation and no reason to believe that such an implementation | implementation and no reason to believe that such an implementation | |||
would ever have been built. Therefore, it seems safe to ignore this | would ever have been built. Therefore, it seems safe to ignore this | |||
issue. | 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. | |||
skipping to change at page 15, line 25 | skipping to change at page 15, line 20 | |||
The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field | The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field | |||
to encode PCN-marks. One codepoint allows non-PCN traffic to be | to encode PCN-marks. One codepoint allows non-PCN traffic to be | |||
carried with the same PCN-compatible DSCP and three other codepoints | carried with the same PCN-compatible DSCP and three other codepoints | |||
support three PCN marking states with different levels of severity. | support three PCN marking states with different levels of severity. | |||
In general, the use of this PCN encoding scheme presupposes that any | In general, the use of this PCN encoding scheme presupposes that any | |||
tunnel endpoints within the PCN-domain comply with [RFC6040]. | tunnel endpoints within the PCN-domain comply with [RFC6040]. | |||
10. Acknowledgements | 10. Acknowledgements | |||
Many thanks to Phil Eardley for providing extensive feedback, | Many thanks to Phil Eardley for providing extensive feedback, | |||
critcism and advice. Thanks also to Teco Boot, Kwok Ho Chan, | criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan, | |||
Ruediger Geib, Georgios Karaginannis and everyone else who has | Ruediger Geib, Georgios Karaginannis and everyone else who has | |||
commented on the document. | 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 | |||
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 | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | in RFCs to Indicate Requirement | |||
Levels", BCP 14, RFC 2119, | ||||
March 1997. | ||||
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, | |||
"Definition of the Differentiated Services Field (DS | F., and D. Black, "Definition of | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, | the Differentiated Services Field | |||
December 1998. | (DS Field) in the IPv4 and IPv6 | |||
Headers", RFC 2474, | ||||
December 1998. | ||||
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | [RFC3168] Ramakrishnan, K., Floyd, S., and | |||
of Explicit Congestion Notification (ECN) to IP", | D. Black, "The Addition of | |||
RFC 3168, September 2001. | Explicit Congestion Notification | |||
(ECN) to IP", RFC 3168, | ||||
September 2001. | ||||
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) | [RFC5559] Eardley, P., "Pre-Congestion | |||
Architecture", RFC 5559, June 2009. | Notification (PCN) Architecture", | |||
RFC 5559, June 2009. | ||||
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- | [RFC5670] Eardley, P., "Metering and | |||
Nodes", RFC 5670, November 2009. | Marking Behaviour of PCN-Nodes", | |||
RFC 5670, November 2009. | ||||
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion | [RFC6040] Briscoe, B., "Tunnelling of | |||
Notification", RFC 6040, November 2010. | Explicit Congestion | |||
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., | |||
Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. | Karagiannis, G., Menth, M., and | |||
Taylor, "PCN Boundary Node Behaviour for the Controlled | T. Taylor, "PCN Boundary Node | |||
Load (CL) Mode of Operation", | Behaviour for the Controlled Load | |||
draft-ietf-pcn-cl-edge-behaviour-09 (work in progress), | (CL) Mode of Operation", draft- | |||
June 2011. | ietf-pcn-cl-edge-behaviour-09 | |||
(work in progress), June 2011. | ||||
[I-D.ietf-pcn-encoding-comparison] | [I-D.ietf-pcn-encoding-comparison] Karagiannis, G., Chan, K., | |||
Karagiannis, G., Chan, K., Moncaster, T., Menth, M., | Moncaster, T., Menth, M., | |||
Eardley, P., and B. Briscoe, "Overview of Pre-Congestion | Eardley, P., and B. Briscoe, | |||
Notification Encoding", | "Overview of Pre-Congestion | |||
draft-ietf-pcn-encoding-comparison-06 (work in progress), | Notification Encoding", draft- | |||
June 2011. | ietf-pcn-encoding-comparison-06 | |||
(work in progress), June 2011. | ||||
[I-D.ietf-pcn-sm-edge-behaviour] | [I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., | |||
Charny, A., Karagiannis, G., Menth, M., and T. Taylor, | Menth, M., and T. Taylor, "PCN | |||
"PCN Boundary Node Behaviour for the Single Marking (SM) | Boundary Node Behaviour for the | |||
Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-06 | Single Marking (SM) Mode of | |||
(work in progress), June 2011. | Operation", draft-ietf-pcn-sm- | |||
edge-behaviour-06 (work in | ||||
progress), June 2011. | ||||
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, | [RFC2597] Heinanen, J., Baker, F., Weiss, | |||
"Assured Forwarding PHB Group", RFC 2597, June 1999. | 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., Courtney, W., Davari, S., Firoiu, V., and D. | J., Benson, K., Le Boudec, J., | |||
Stiliadis, "An Expedited Forwarding PHB (Per-Hop | Courtney, W., Davari, S., Firoiu, | |||
Behavior)", RFC 3246, March 2002. | 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 | [RFC3540] Spring, N., Wetherall, D., and D. | |||
Congestion Notification (ECN) Signaling with Nonces", | Ely, "Robust Explicit Congestion | |||
RFC 3540, June 2003. | Notification (ECN) Signaling with | |||
Nonces", RFC 3540, June 2003. | ||||
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration | [RFC4594] Babiarz, J., Chan, K., and F. | |||
Guidelines for DiffServ Service Classes", RFC 4594, | Baker, "Configuration Guidelines | |||
August 2006. | for DiffServ Service Classes", | |||
RFC 4594, August 2006. | ||||
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the | [RFC4774] Floyd, S., "Specifying Alternate | |||
Explicit Congestion Notification (ECN) Field", BCP 124, | Semantics for the Explicit | |||
RFC 4774, November 2006. | Congestion Notification (ECN) | |||
Field", BCP 124, RFC 4774, | ||||
November 2006. | ||||
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of | [RFC5127] Chan, K., Babiarz, J., and F. | |||
DiffServ Service Classes", RFC 5127, February 2008. | Baker, "Aggregation of DiffServ | |||
Service Classes", RFC 5127, | ||||
February 2008. | ||||
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion | [RFC5129] Davie, B., Briscoe, B., and J. | |||
Marking in MPLS", RFC 5129, January 2008. | Tay, "Explicit Congestion Marking | |||
in MPLS", RFC 5129, January 2008. | ||||
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching | [RFC5462] Andersson, L. and R. Asati, | |||
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic | "Multiprotocol Label Switching | |||
Class" Field", RFC 5462, February 2009. | (MPLS) Label Stack Entry: "EXP" | |||
Field Renamed to "Traffic Class" | ||||
Field", RFC 5462, February 2009. | ||||
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline | [RFC5696] Moncaster, T., Briscoe, B., and | |||
Encoding and Transport of Pre-Congestion Information", | M. Menth, "Baseline Encoding and | |||
RFC 5696, November 2009. | Transport of Pre-Congestion | |||
Information", RFC 5696, | ||||
November 2009. | ||||
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated | [RFC5865] Baker, F., Polk, J., and M. | |||
Services Code Point (DSCP) for Capacity-Admitted Traffic", | Dolly, "A Differentiated Services | |||
RFC 5865, May 2010. | Code Point (DSCP) for Capacity- | |||
Admitted Traffic", RFC 5865, | ||||
May 2010. | ||||
Appendix A. Choice of Suitable DSCPs | Appendix A. Choice of Suitable DSCPs | |||
This appendix is informative, not normative. | This appendix is informative, not normative. | |||
A single DSCP has not been defined for use with PCN for several | A single DSCP has not been defined for use with PCN for several | |||
reasons. Firstly, the PCN mechanism is applicable to a variety of | reasons. Firstly, the PCN mechanism is applicable to a variety of | |||
different traffic classes. Secondly, Standards Track DSCPs are in | different traffic classes. Secondly, Standards Track DSCPs are in | |||
increasingly short supply. Thirdly, PCN is not a scheduling | increasingly short supply. Thirdly, PCN is not a scheduling | |||
behaviour -- rather, it should be seen as being a marking behaviour | behaviour -- rather, it should be seen as being a marking behaviour | |||
skipping to change at page 18, line 46 | skipping to change at page 19, line 21 | |||
This appendix is informative, not normative. | 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] (obsoleted) included advice | the PCN domain. Appendix B of [RFC5696] (obsoleted) included advice | |||
on handling ECN traffic within a PCN-domain. This appendix | on handling ECN traffic within a PCN-domain. This appendix | |||
reiterates and clarifies that 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 re-marked to a PCN-compatible | Admission-controlled traffic will be re-marked 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, which associates a filterspec with a need for | |||
control (e.g. through RSVP or some equivalent message, e.g. from | admission control (e.g. through RSVP or some equivalent message, | |||
a SIP server to the ingress), and the PCN-ingress re-marks | e.g. from a SIP server to the ingress); the PCN-ingress-node re- | |||
traffic matching that filterspec to a PCN-compatible DSCP, as its | marks traffic matching that filterspec to a PCN-compatible DSCP. | |||
chosen 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 Real-Time Interactive, | |||
Broadcast TV when used for video on demand, and Multimedia | Broadcast Video when used for video on demand, and multimedia | |||
Conferencing [RFC4594][RFC5865] (see Appendix A). | conferencing [RFC4594][RFC5865] (see Appendix A). | |||
All other traffic can be thought of as Non-admission-controlled (and | All other traffic can be thought of as non-admission-controlled (and | |||
therefore outside the scope of PCN). However such traffic may still | therefore outside the scope of PCN). However such traffic may still | |||
need to share the same DSCP as the Admission-controlled traffic. | need to share the same DSCP as the admission-controlled traffic. | |||
This may be due to policy (for instance if it is high priority voice | This may be due to policy (for instance if it is high priority voice | |||
traffic), or may be because there is a shortage of local DSCPs. | traffic), or may be because there is a shortage of local DSCPs. | |||
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. | also be ECN capable. | |||
Unless specified otherwise, for any of the cases in the list below, | Unless specified otherwise, for any of the cases in the list below, | |||
an IP-in-IP tunnel can be used to preserve ECN markings across the | an IP-in-IP tunnel can be used to preserve ECN markings across the | |||
PCN domain. The tunnelling action should be applied wholly outside | PCN domain. The tunnelling action should be applied wholly outside | |||
skipping to change at page 19, line 43 | skipping to change at page 20, line 16 | |||
. ,--------. ,--------. . | . ,--------. ,--------. . | |||
. _| 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 tunnelling and PCN actions | |||
There are three cases for how e2e ECN traffic may wish to be treated | There are three cases for how e2e ECN traffic may wish to be treated | |||
while crossing a PCN domain: | while crossing a PCN domain: | |||
a) Does not require admission control: | a) Traffic that does not require admission control: | |||
For example, traffic that does not match flow signaling being used | ||||
for admission control. In this case the e2e ECN traffic is not | ||||
treated as PCN-traffic. There are two possible scenarios: | ||||
* Does not carry a PCN-compatible DSCP: No action required. | * Arriving traffic does not carry a PCN-compatible DSCP: no | |||
action required. | ||||
* Arrives carrying a DSCP that uses the same codepoint as a PCN- | * Arriving traffic carries a DSCP that clashes with a PCN- | |||
compatible DSCP: There are two options: | compatible DSCP. There are two options: | |||
1. The ingress maps the DSCP to a local DSCP with the same | 1. The ingress maps the DSCP to a local DSCP with the same | |||
scheduling PHB as the original DSCP, and the egress re-maps | scheduling PHB as the original DSCP, and the egress re-maps | |||
it to the original PCN-compatible DSCP. | it to the original PCN-compatible DSCP. | |||
2. The ingress tunnels the traffic, setting not-PCN in the | 2. The ingress tunnels the traffic, setting not-PCN in the | |||
outer header; note that this turns off ECN for this traffic | outer header; note that this turns off ECN for this traffic | |||
within the PCN domain. | within the PCN domain. | |||
The first option is recommended unless the operator is short of | The first option is recommended unless the operator is short of | |||
local DSCPs. | local DSCPs. | |||
b) Requires Admission-control: There are two options. | b) Traffic that requires admission-control: | |||
In this case the e2e ECN traffic is treated as PCN-traffic across | ||||
the PCN domain. There are two options. | ||||
* The PCN-ingress places this traffic in a tunnel with a PCN- | * The PCN-ingress-node places this traffic in a tunnel with a | |||
compatible DSCP in the outer header. The PCN-egress zeroes the | PCN-compatible DSCP in the outer header. The PCN-egress zeroes | |||
ECN-field before decapsulation. | the ECN-field before decapsulation. | |||
* The PCN-ingress drops CE-marked packets and the PCN-egress | * The PCN-ingress-node drops CE-marked packets and otherwise sets | |||
zeros the ECN field of all PCN packets. | the ECN-field to NM and sets the DCSP to a PCN-compatible DSCP. | |||
The PCN-egress zeroes the ECN field of all PCN packets; note | ||||
that this turns off e2e ECN. | ||||
The second option is emphatically not recommended, unless perhaps | The second option is emphatically not recommended, unless perhaps | |||
as a last resort if tunnelling is not possible for some | as a last resort if tunnelling is not possible for some | |||
insurmountable reason. | insurmountable reason. | |||
c) Requires Admission Control and asks to see PCN marks: NOTE this | c) Traffic that requires admission control where the endpoints ask to | |||
scheme is currently only a tentative idea. | see PCN marks: | |||
Note that this scheme is currently only a tentative idea. | ||||
For real-time data generated by an adaptive codec, schemes have | For real-time data generated by an adaptive codec, schemes have | |||
been suggested where PCN marks may be leaked out of the PCN-domain | been suggested where PCN marks may be leaked out of the PCN-domain | |||
so that end hosts can drop to a lower data rate, thus deferring | so that end hosts can drop to a lower data rate, thus deferring | |||
the need for admission control. Currently such schemes require | the need for admission control. Currently such schemes require | |||
further study and the following is for guidance only. | further study and the following is for guidance only. | |||
The PCN-ingress needs to tunnel the traffic as in Figure 2, taking | The PCN-ingress-node needs to tunnel the traffic as in Figure 2, | |||
care to comply with [RFC6040]. In this case the PCN-egress should | taking care to comply with [RFC6040]. In this case the PCN-egress | |||
not zero the ECN field, and then the [RFC6040] tunnel egress will | does not zero the ECN field contrary to the recommendation in | |||
preserve any PCN-marking. Note that a PCN interior node may turn | Section 5.3, so that the [RFC6040] tunnel egress will preserve any | |||
ECT(0) into ECT(1), which would not be compatible with the | PCN-marking. Note that a PCN interior node may change the ECN- | |||
(currently experimental) ECN nonce [RFC3540]. | field from 10 to 01 (NM to ThM), which would be interpreted by the | |||
e2e ECN as a change from ECT(0) into ECT(1). This would not be | ||||
compatible with the (currently experimental) ECN nonce [RFC3540]. | ||||
Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in | Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in | |||
MPLS Shim Headers | MPLS Shim Headers | |||
This appendix is informative not normative. | This appendix is informative not normative. | |||
The 6 bits of the DS field in the IP header provide for 64 | The 6 bits of the DS field in the IP header provide for 64 | |||
codepoints. When encapsulating IP traffic in MPLS, it is useful to | codepoints. When encapsulating IP traffic in MPLS, it is useful to | |||
make the DS field information accessible in the MPLS header. | make the DS field information accessible in the MPLS header. | |||
However, the MPLS shim header has only a 3-bit traffic class (TC) | However, the MPLS shim header has only a 3-bit traffic class (TC) | |||
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 the 64 codepoints of the DS | freedom to define a site-local mapping of the 64 codepoints of the DS | |||
field onto the 8 codepoints in the TC field. | field onto the 8 codepoints in the TC field. | |||
[RFC5129] describes how ECN markings in the IP header can also be | [RFC5129] describes how ECN markings in the IP header can also be | |||
mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129] | mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129] | |||
gives an informative description of how to support PCN in MPLS by | gives an informative description of how to support PCN in MPLS by | |||
extending the way MPLS supports ECN. But [RFC5129] was written while | extending the way MPLS supports ECN. [RFC5129] was written while PCN | |||
PCN specifications were in early draft stages. The following | specifications were in early draft stages. The following provides a | |||
provides a clearer example of a mapping between PCN in IP and in MPLS | clearer example of a mapping between PCN in IP and in MPLS using the | |||
using the PCN terminology and concepts that have since been | PCN terminology and concepts that have since been specified. | |||
specified. | ||||
To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n') | To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n') | |||
needs codepoints to be provided in the TC field for all the PCN-marks | needs codepoints to be provided in the TC field for all the PCN-marks | |||
used. That means, when for instance only excess-traffic-marking is | used. That means, when for instance only excess-traffic-marking is | |||
used for PCN purposes, the operator needs to define a site-local | used for PCN purposes, the operator needs to define a site-local | |||
mapping to two codepoints in the MPLS TC field for IP headers with: | mapping to two codepoints in the MPLS TC field for IP headers with: | |||
o DSCP n and ECT(0) | o DSCP n and NM | |||
o DSCP n and CE | o DSCP n and ETM | |||
If both excess-traffic-marking and threshold-marking are used, the | If both excess-traffic-marking and threshold-marking are used, the | |||
operator needs to define a site-local mapping to codepoints in the | operator needs to define a site-local mapping to codepoints in the | |||
MPLS TC field for IP headers with all three of the 3-in-1 codepoints: | MPLS TC field for IP headers with all three of the 3-in-1 codepoints: | |||
o DSCP n and ECT(0) | o DSCP n and NM | |||
o DSCP n and ECT(1) | o DSCP n and ThM | |||
o DSCP n and CE | o DSCP n and ETM | |||
In either case, if the operator wishes to support the same Diffserv | In either case, if the operator wishes to support the same Diffserv | |||
PHB but without PCN marking, it will also be necessary to define a | PHB but without PCN marking, it will also be necessary to define a | |||
site-local mapping to an MPLS TC codepoint for IP headers marked | site-local mapping to an MPLS TC codepoint for IP headers marked | |||
with: | with: | |||
o DSCP n and Not-ECT | o DSCP n and Not-PCN | |||
Clearly, given so few TC codepoints are available, it may be | The above sets of codepoints are required for every PCN-compatible | |||
DSCP. Clearly, given so few TC codepoints are available, it may be | ||||
necessary to compromise by merging together some capabilities. | necessary to compromise by merging together some capabilities. | |||
Appendix D. Rationale for Discrepancy Between the Schemes using One | Appendix D. Rationale for Difference Between the Schemes using One PCN- | |||
PCN-Marking | Marking | |||
Readers may notice an apparent discrepancy between the two behaviours | Readers may notice a difference between the two behaviours in | |||
in Section 5.2.3.1 and Section 5.2.3.2. With only excess-traffic | Section 5.2.3.1 and Section 5.2.3.2. With only excess-traffic | |||
marking enabled, an unexpected ThM packet can be re-marked to ETM. | marking enabled, an unexpected ThM packet can be re-marked to ETM. | |||
However, with only threshold marking, an unexpected ETM packet cannot | However, with only Threshold-marking, an unexpected ETM packet cannot | |||
be re-marked to ThM. | be re-marked to ThM. | |||
This apparent inconsistency is deliberate, for two reasons: | This apparent inconsistency is deliberate. The behaviour with only | |||
threshold marking keeps to the rule of Section 5.2.1 that ETM is more | ||||
o If only one type of marking function is meant to be used | severe and must never be changed to ThM even though ETM is not a | |||
throughout the PCN-domain but the other type unexpectedly appears | valid marking in this case. Otherwise implementations would have to | |||
on some packets, it is safest to assume that some link is trying | allow operators to configure an exception to this rule, which would | |||
to signal that it is pre-congested, but that it is somehow using | not be safe practice and would require different code in the data | |||
the wrong signal. This only needs to be corrected if the | plane compared to the common behaviour. | |||
behaviour of other nodes depends on the marking a packet arrives | ||||
with. In [RFC5670], the excess-traffic-metering behaviour depends | ||||
on the markings on arriving packets, whereas threshold-metering | ||||
does not. Therefore, if ThM should not be present, it seems safe | ||||
to allow it to be re-marked to ETM, but if ETM should not be | ||||
present there is no need to re-mark it to ThM. | ||||
o The behaviour with only threshold marking keeps to the rule that | ||||
ETM is more severe and must never be changed to ThM even though | ||||
ETM is not a valid marking in this case. Otherwise | ||||
implementations would have to allow operators to configure an | ||||
exception to this rule, which would not be safe practice. | ||||
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 | |||
Phone: +44 1473 645196 | Phone: +44 1473 645196 | |||
Email: bob.briscoe@bt.com | EMail: bob.briscoe@bt.com | |||
URI: http://bobbriscoe.net/ | URI: http://bobbriscoe.net/ | |||
Toby Moncaster | Toby Moncaster | |||
Moncaster Internet Consulting | Moncaster Internet Consulting | |||
Dukes | Dukes | |||
Layer Marney | Layer Marney | |||
Colchester CO5 9UZ | Colchester CO5 9UZ | |||
UK | UK | |||
Phone: +44 7764 185416 | Phone: +44 7764 185416 | |||
Email: toby@moncaster.com | EMail: toby@moncaster.com | |||
URI: http://www.moncaster.com/ | URI: http://www.moncaster.com/ | |||
Michael Menth | Michael Menth | |||
University of Tuebingen | University of Tuebingen | |||
Sand 13 | Sand 13 | |||
Tuebingen 72076 | Tuebingen 72076 | |||
Germany | Germany | |||
Phone: +49 7071 2970505 | Phone: +49 7071 2970505 | |||
Email: menth@informatik.uni-tuebingen.de | EMail: menth@informatik.uni-tuebingen.de | |||
End of changes. 89 change blocks. | ||||
206 lines changed or deleted | 238 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/ |