Internet Engineering Task Force (IETF) G. Karagiannis
Request for Comments: 6627 University of Twente
Category: Informational K. Chan
ISSN: 2070-1721 Consultant
T. Moncaster
University of Cambridge
M. Menth
University of Tuebingen
P. Eardley
B. Briscoe
BT
July 2012
Overview of Pre-Congestion Notification Encoding
Abstract
The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain.
On every link in the PCN-domain, the overall rate of PCN-traffic is
metered, and PCN-packets are appropriately marked when certain
configured rates are exceeded. Egress nodes provide decision points
with information about the PCN-marks of PCN-packets that allows them
to take decisions about whether to admit or block a new flow request,
and to terminate some already admitted flows during serious
pre-congestion.
The PCN working group explored a number of approaches for encoding
this pre-congestion information into the IP header. This document
provides details of those approaches along with an explanation of the
constraints that apply to any solution.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6627.
Karagiannis, et al. Informational [Page 1]
RFC 6627 Pre-Congestion Notification Encoding July 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Karagiannis, et al. Informational [Page 2]
RFC 6627 Pre-Congestion Notification Encoding July 2012 Table of Contents 1. Introduction ....................................................4 2. General PCN Encoding Requirements ...............................5 2.1. Metering and Marking Algorithms ............................5 2.2. Approaches for PCN-Based Admission Control and Flow Termination ................................................5 2.2.1. Dual Marking (DM) ...................................5 2.2.2. Single Marking (SM) .................................6 2.2.3. Packet-Specific Dual Marking (PSDM) .................7 2.2.4. Preferential Packet Dropping ........................8 3. Encoding Constraints ............................................9 3.1. Structure of the DS Field ..................................9 3.2. Constraints from the DS Field ..............................9 3.2.1. General Scarcity of DSCPs ...........................9 3.2.2. Handling of the DSCP in Tunneling Rules ............10 3.2.3. Restoration of Original DSCPs at the Egress Node ...10 3.3. Constraints from the ECN Field ............................11 3.3.1. Structure and Use of the ECN Field .................11 3.3.2. Redefinition of the ECN Field ......................12 3.3.3. Handling of the ECN Field in Tunneling Rules .......12 3.3.3.1. Limited-Functionality Option ..............12 3.3.3.2. Full-Functionality Option .................13 3.3.3.3. Tunneling with IPSec ......................13 3.3.3.4. ECN Tunneling .............................13 3.3.4. Restoration of the Original ECN Field at the PCN-Egress-Node ................................14 4. Comparison of Encoding Options .................................15 4.1. Baseline Encoding .........................................15 4.2. Encoding with 1 DSCP Providing 3 States ...................16 4.3. Encoding with 2 DSCPs Providing 3 or More States ..........16 4.4. Encoding for Packet-Specific Dual Marking (PSDM) ..........16 4.5. Standardized Encodings ....................................17 5. Conclusion .....................................................17 6. Security Implications ..........................................17 7. Acknowledgements ...............................................17 8. References .....................................................18 8.1. Normative References ......................................18 8.2. Informative References ....................................18 Karagiannis, et al. Informational [Page 3]
RFC 6627 Pre-Congestion Notification Encoding July 2012 1. Introduction The objective of Pre-Congestion Notification (PCN) [RFC5559] is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. Two mechanisms are used: admission control (AC), to decide whether to admit or block a new flow request, and flow termination (FT), to terminate some existing flows during serious pre-congestion. To achieve this, the overall rate of PCN-traffic is metered on every link in the domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. These configured rates are below the rate of the link. Thus, boundary nodes are notified of a potential overload before any real congestion occurs (hence "pre- congestion notification"). [RFC5670] provides for two metering and marking functions that are configured with reference rates. Threshold-marking marks all PCN- packets once their traffic rate on a link exceeds the configured reference rate (PCN-threshold-rate). Excess-traffic-marking marks only those PCN-packets that exceed the configured reference rate (PCN-excess-rate). Egress nodes monitor the PCN-marks of received PCN-packets and provide information about the PCN-marks to the decision points that take decisions about the flow admission and termination on this basis [RFC6661] [RFC6662]. This PCN information has to be encoded into the IP header. This requires at least three different codepoints: one for PCN-traffic that has not been marked, one for traffic that has been marked by the threshold meter, and one for traffic that has been marked by the excess-traffic-meter. Since unused codepoints are not available for that purpose in the IP header (versions 4 and 6), already used codepoints must be reused, which imposes additional constraints on the design and applicability of PCN-based AC and FT. This document summarizes these issues as a record of the PCN working group discussions and for the benefit of the wider IETF community. In Section 2, we briefly point out the PCN encoding requirement imposed by metering and marking algorithms, and by special packet drop strategies. The Differentiated Services field (6 bits -- see [RFC3260] updating [RFC2474] in this respect) and the Explicit Congestion Notification (ECN) field (2 bits) [RFC3168] have been selected to be reused for encoding of PCN-marks (PCN encoding). In Section 3, we briefly explain the constraints imposed by this decision. In Section 4, we review different PCN encodings considered Karagiannis, et al. Informational [Page 4]
RFC 6627 Pre-Congestion Notification Encoding July 2012 by the PCN working group that allow different implementations of PCN- based AC and FT, which have different pros and cons. 2. General PCN Encoding Requirements The choice of metering and marking algorithms and the way they are applied to PCN-based AC and FT impose certain requirements on PCN encoding. 2.1. Metering and Marking Algorithms Two different metering and marking algorithms are defined in [RFC5670]: excess-traffic-marking and threshold-marking. They are both configured with reference rates that are termed PCN-excess-rate and PCN-threshold-rate, respectively. When traffic for PCN-flows enters a PCN-domain, the PCN-ingress-node sets a codepoint in the IP header indicating that the packet is subject to PCN-metering and PCN- marking and that it is not-marked (NM). The two metering and marking algorithms possibly re-mark PCN-packets as excess-traffic-marked (ETM) or threshold-marked (ThM). Excess-traffic-marking ETM-marks all not-ETM-marked PCN-traffic that is in excess of the PCN-excess-rate. To that end, the algorithm needs to know whether a PCN-packet has already been marked with ETM or not. Threshold-marking re-marks all not-marked PCN-traffic to ThM when the rate of PCN-traffic exceeds the PCN-threshold-rate. Therefore, it does not need knowledge of the prior marking state of the packet for metering, but such knowledge is needed for packet re-marking. 2.2. Approaches for PCN-Based Admission Control and Flow Termination We briefly review three different approaches to implement PCN-based AC and FT and derive their requirements for PCN encoding. 2.2.1. Dual Marking (DM) The intuitive approach for PCN-based AC and FT requires that threshold and excess-traffic-marking are simultaneously activated on all links of a PCN-domain, and their reference rates are configured with the PCN-admissible-rate (AR) and the PCN-supportable-rate (SR), respectively. Threshold-marking meters all PCN-traffic, but re-marks only NM-traffic to ThM. Excess-traffic-marking meters only NM- and ThM-traffic and re-marks it to ETM. Thus, both meters and markers need to identify PCN-packets and their exact PCN codepoint. We call this marking behavior dual marking (DM) and Figure 1 illustrates all possible re-marking actions. Karagiannis, et al. Informational [Page 5]
RFC 6627 Pre-Congestion Notification Encoding July 2012 NM -----------> ThM \ / \ / \ / > ETM < Figure 1: PCN Codepoint Re-Marking Diagram for Dual Marking (DM) Dual marking is used to support the Controlled-Load PCN (CL-PCN) edge behavior [RFC6661]. We briefly summarize the concept. All actions are performed on per-ingress-egress-aggregate basis. The egress node measures the rate of NM-, ThM-, and ETM-traffic in regular intervals and sends them as PCN egress reports to the AC and FT decision point. If the proportion of re-marked (ThM- and ETM-) PCN-traffic is larger than a defined threshold, called CLE-limit, the decision point blocks new flow requests until new PCN egress reports are received; otherwise, it admits them. With CL-PCN, AC is rather robust with regard to the value chosen for the CLE-limit. FT works as follows. If the ETM-traffic rate is positive, the decision point triggers the ingress node to send a newly measured rate of the sent PCN-traffic. The decision point calculates the rate of PCN-traffic that needs to be terminated by termination-rate = PCN-sent-rate - (rate-of-NM-traffic + rate-of-ThM-traffic) and terminates an appropriate set of flows. CL-PCN is accurate enough for most application scenarios and its implementation complexity is acceptable, therefore, it is a preferred implementation option for PCN-based AC and FT. 2.2.2. Single Marking (SM) Single marking uses only excess-traffic-marking whose reference rate is set to the PCN-admissible-rate (AR) on all links of the PCN- domain. Figure 2 illustrates all possible re-marking actions. NM --------> ETM Figure 2: PCN Codepoint Re-Marking Diagram for Single Marking (SM) Single marking is used to support the Single-Marking PCN (SM-PCN) edge behavior [RFC6662]. We briefly summarize the concept. Karagiannis, et al. Informational [Page 6]
RFC 6627 Pre-Congestion Notification Encoding July 2012 AC works essentially in the same way as with CL-PCN, but AC is sensitive to the value of the CLE-limit. Also FT works similarly to CL-PCN. The PCN-supportable-rate (SR) is not configured on any link, but is implicitly SR=u*AR in the PCN-domain using a network-wide constant u. The decision point triggers FT only if the rate-of-NM-traffic * u < rate-of-NM- traffic + rate-of-ETM-traffic. Then it requests the PCN-sent-rate from the corresponding PCN-ingress-node and calculates the amount of PCN-traffic to be terminated by termination-rate = PCN-sent-rate - rate-of-NM-traffic * u, and terminates an appropriate set of flows. SM-PCN requires only two PCN codepoints and only excess-traffic- marking is needed, which means that it might be earlier to the market than CL-PCN since some chipsets do not yet support threshold-marking. However, it only works well when ingress-egress-aggregates have a high PCN-packet rate, which is not always the case. Otherwise, over- admission and over-termination may occur [Menth12] [Menth10]. 2.2.3. Packet-Specific Dual Marking (PSDM) Packet-specific dual marking (PSDM) uses threshold-marking and excess-traffic-marking, whose reference rates are configured with the PCN-admissible-rate (AR) and the PCN-supportable-rate (SR), respectively. There are two different types of not-marked packets: those that are subject to threshold-marking (not-ThM), and those that are subject to excess-traffic-marking (not-ETM). Both not-ThM and not-ETM are used for PCN-traffic that is not yet re-marked (like NM with single and dual marking), and their specific use is determined by higher-layer information (see below). Threshold-marking meters all PCN-traffic and re-marks only not-ThM packets to PCN-marked (PM). In contrast, excess-traffic-marking meters only not-ETM packets and possibly re-marks them to PM, too. Again, both meters and markers need to identify PCN-packets and their exact PCN codepoint. Figure 3 illustrates all possible re-marking actions. Karagiannis, et al. Informational [Page 7]
RFC 6627 Pre-Congestion Notification Encoding July 2012 not-ThM not-ETM \ / \ / \ / > PM < Figure 3: PCN Codepoint Re-Marking Diagram for Packet-Specific Dual Marking (PSDM) An edge behavior for PSDM has been presented in [Menth09] and [PCN- MS-AC]. We call it PSDM-PCN. In contrast to CL-PCN and SM-PCN, AC is realized by reusing initial signaling messages for probing purposes. The assumption is that admission requests are triggered by an external end-to-end signaling protocol, e.g., RSVP [RFC2205]. Signaling traffic for a flow is also labeled as PCN-traffic, and if an initial signaling message traverses the PCN-domain and is re-marked, then the corresponding admission request is blocked. This is a lightweight probing mechanism that does not generate extra traffic and does not introduce probing delay. In PSDM-PCN, PCN-ingress-nodes label initial signaling messages as not-ThM, and threshold-marking configured with admissible rates possibly re-marks them to PM. Data packets are labeled with not-ETM, and excess-traffic-marking configured with supportable rates possibly re-marks them to PM, too, so that the same algorithms for FT may be used as for CL-PCN and SM-PCN. PSDM has three major disadvantages. First, signalling traffic needs to be marked with a PCN-enabled DSCP so that it either shares the same queue as data traffic, which may not be desired by some operators, or multiple PCN-enabled DSCPs are needed, which is not a pragmatic solution. Second, reservations for PCN-flows need to be triggered by a path-coupled end-to-end signalling protocol, which restricts the choice of the signalling protocol. And third, the selected signalling protocols must be adapted to take advantage of PCN-marked signalling messages for admission decisions, which incurs some extra effort before PSDM can be used. The advantages are that the AC algorithm is more accurate than the one of CL-PCN and SM-PCN [Menth12], that often only a single DSCP is needed, and that the new tunneling rules in [RFC6040] are not needed for deployment (Section 3.3.3). 2.2.4. Preferential Packet Dropping The termination algorithms described in [RFC6661] and [RFC6662] require the preferential dropping of ETM-marked packets to avoid over-termination in the case of packet loss. An analysis explaining this phenomenon can be found in Section 4 of [Menth10]. Karagiannis, et al. Informational [Page 8]
RFC 6627 Pre-Congestion Notification Encoding July 2012 Thus, [RFC5670] recommends that ETM-marked packets "SHOULD be preferentially dropped". As a consequence, droppers must have access to the exact marking information of PCN-packets. 3. Encoding Constraints The PCN working group decided to use a combination of the 6-bit Differentiated Services (DS) field and the ECN field for the encoding of the PCN-marks (see [RFC6660]). This section describes the criteria that are used to compare the resulting encoding options described in Section 4. 3.1. Structure of the DS Field Figure 4 shows the structure of the DS and ECN fields. [RFC0793] defined the 8-bit TOS octet and [RFC2474] redefined it as the DS field, including the two least significant bits as currently unused (CU). [RFC3168] assigned the two CU bits to ECN and [RFC3260] redefined the DS field as only the most significant 6-bits of the (former) IPv4 TOS octet, thus separating the two-bit ECN field from the DS field. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | DS | ECN | +---+---+---+---+---+---+---+---+ DS: Differentiated Services field [RFC2474], [RFC3260] ECN: ECN field [RFC3168] Figure 4: The Structure of the DS and ECN Fields 3.2. Constraints from the DS Field The Differentiated Services Codepoint (DSCP) set in the DS field indicates the per-hop behavior (PHB), i.e., the treatment IP packets receive from nodes in a DS domain. Multiple DSCPs may indicate the same PHB. PCN-traffic is high-priority traffic, which uses a DSCP (or DSCPs) that indicates a PHB with preferred treatment. 3.2.1. General Scarcity of DSCPs As the number of unused DSCPs is small, PCN encoding should use only one additional DSCP for each DSCP originally used to indicate the PHB and in any case should not use more than two. Therefore, the DSCP should be used to indicate that traffic is subject to PCN-metering and PCN-marking, but not to differentiate various PCN-markings. Karagiannis, et al. Informational [Page 9]
RFC 6627 Pre-Congestion Notification Encoding July 2012 3.2.2. Handling of the DSCP in Tunneling Rules PCN encoding must be chosen in such a way that PCN-traffic can be tunneled within a PCN-domain without any impact on PCN-metering and re-marking. In the following, the "inner header" refers to the header of the encapsulated packet and the "outer header" refers to the encapsulating header. [RFC2983] provides two tunneling modes for Differentiated Services networks. The uniform model copies the DSCP from the inner header to the outer header upon encapsulation, and it copies the DSCP from the outer header to the inner header upon decapsulation. This assures that changes applied to the DSCP field survive encapsulation and decapsulation. In contrast, the pipe model ignores the content of the DSCP field in the outer header upon decapsulation. Therefore, decapsulation erases changes applied to the DSCP along the tunnel. As a consequence, only the uniform model may be used for tunneling PCN-traffic within a PCN-domain, if PCN encoding uses more than a single DSCP. 3.2.3. Restoration of Original DSCPs at the Egress Node If PCN-marking does not alter the original DSCP, the traffic leaves the PCN-domain with its original DSCP. However, if the PCN-marking alters the DSCP, then some additional technique is needed to restore the original DSCP. A few possibilities are discussed: 1. Each Diffserv class using PCN uses a different set of DSCPs. Therefore, if there are M DSCPs using PCN and PCN encoding uses N different DSCPs, N*M DSCPs are needed. This solution may work well in IP networks. However, when PCN is applied to MPLS networks or other layers restricted to 8 QoS classes and codepoints, this solution fails due to the extreme shortage of available DSCPs. 2. The original DSCP for the packets of a flow is signaled to the egress node. No suitable signaling protocol has been developed and, therefore, it is not clear whether this approach could work. 3. PCN-traffic is tunneled across the PCN-domain. The pipe- tunneling model is applied, so the original DSCP is restored after decapsulation. However, tunneling across a PCN-domain adds an additional IP header and reduces the maximum transfer unit (MTU) from the perspective of the user. GRE, MPLS, or Ethernet using pseudowires are potential solutions that scale well in backbone networks. Karagiannis, et al. Informational [Page 10]
RFC 6627 Pre-Congestion Notification Encoding July 2012 The most appropriate option depends on the specific circumstances an operator faces. o Option 1 is most suitable unless there is a shortage of available DSCPs. o Option 3 is suitable where the reduction of MTU is not liable to cause issues. 3.3. Constraints from the ECN Field This section briefly reviews the structure and use of the ECN field. The ECN field may be redefined, but certain constraints apply [RFC4774]. The impact on PCN deployment is discussed, as well as the constraints imposed by various tunneling rules on the persistence of PCN-marks after decapsulation and its impact on possible re-marking actions. 3.3.1. Structure and Use of the ECN Field Some transport protocols, like TCP, can typically use packet drops as an indication of congestion in the Internet. The idea of Explicit Congestion Notification (ECN) [RFC3168] is that routers provide a congestion indication for incipient congestion, where the notification can sometimes be through ECN-marking (and re-marking) packets rather than dropping them. Figure 5 summarizes the ECN codepoints defined [RFC3168]. +-----+-----+ | ECN FIELD | +-----+-----+ 0 0 Not-ECT 0 1 ECT(1) 1 0 ECT(0) 1 1 CE Figure 5: ECN Codepoints within the ECN Field ECT stands for "ECN-capable transport" and indicates that the senders and receivers of a flow understand ECN semantics. Packets of other flows are labeled with Not-ECT. To indicate congestion to a receiver, routers may re-mark ECT(1) or ECT(0) labeled packets to CE, which stands for "congestion experienced". Two different ECT codepoints were introduced "to protect against accidental or malicious concealment of marked packets from the TCP sender", which may be the case with cheating receivers [RFC3540]. Karagiannis, et al. Informational [Page 11]
RFC 6627 Pre-Congestion Notification Encoding July 2012 3.3.2. Redefinition of the ECN Field The ECN field may be redefined for other purposes and [RFC4774] gives guidelines for that. Essentially, Not-ECT-marked packets must never be re-marked to ECT or CE because Not-ECT-capable end systems do not reduce their transmission rate when receiving CE-marked packets. This is a threat to the stability of the Internet. Moreover, CE-marked packets must not be re-marked to Not-ECT or ECT, because then ECN-capable end systems cannot reduce their transmission rate. The reuse of the ECN field for PCN encoding has some impact on the deployment of PCN. First, routers within a PCN-domain must not apply ECN re-marking when the ECN field has PCN semantics. Second, before a PCN-packet leaves the PCN-domain, the egress nodes must either: (A) reset the ECN field of the packet to the content it had when entering the PCN-domain or (B) reset its ECN field to Not-ECT. According to Section 3.3.3, tunneling ECN traffic through a PCN- domain may help to implement (A). When (B) applies, CE-marked packets must never become PCN-packets within a PCN-domain, as the egress node resets their ECN field to Not-ECT. The ingress node may drop such traffic instead. 3.3.3. Handling of the ECN Field in Tunneling Rules When packets are encapsulated, the ECN field of the inner header may or may not be copied to the ECN field of the outer header; upon decapsulation, the ECN field of the outer header may or may not be copied from the ECN field of the outer header to the ECN field of the inner header. Various tunneling rules with different treatment of the ECN field exist. Two different modes are defined in [RFC3168] for IP-in-IP tunnels and a third one in [RFC4301] for IP-in-IPsec tunnels. [RFC6040] updates both of these RFCs to rationalize them into one consistent approach. 3.3.3.1. Limited-Functionality Option The limited-functionality option has been defined in [RFC3168]. Upon encapsulation, the ECN field of the outer header is generally set to Not-ECT. Upon decapsulation, the ECN field of the inner header remains unchanged. Since this tunneling mode loses information upon encapsulation and decapsulation, it cannot be used for tunneling PCN-traffic within a PCN-domain. However, the PCN ingress may use this mode to tunnel traffic with ECN semantics to the PCN egress to preserve the ECN field in the inner header while the ECN field of the outer header is used with PCN semantics within the PCN-domain. Karagiannis, et al. Informational [Page 12]
RFC 6627 Pre-Congestion Notification Encoding July 2012 3.3.3.2. Full-Functionality Option The full-functionality option has been defined in [RFC3168]. Upon encapsulation, the ECN field of the inner header is copied to the outer header unless the ECN field of the inner header carries CE. In that case, the ECN field of the outer header is set to ECT(0). This choice has been made for security reasons, to disable the ECN fields of the outer header as a covert channel. Upon decapsulation, the ECN field of the inner header remains unchanged unless the ECN field of the outer header carries CE. In that case, the ECN field of the inner header is also set to CE. This mode imposes the following constraints on PCN-metering and PCN- marking. First, PCN must re-mark the ECN field only to CE, because any other information is not copied to the inner header upon decapsulation and will be lost. Second, CE information in encapsulated packet headers is invisible for routers along a tunnel. Threshold-marking does not require information about whether PCN- packets have already been marked and would work when CE denotes that packets are marked. In contrast, excess-traffic-marking requires information about already excess-traffic-marked packets and cannot be supported with this tunneling mode. Furthermore, this tunneling mode cannot be used when marked or not-marked packets should be preferentially dropped, because the PCN-marking information is possibly not visible in the outer header of a packet. 3.3.3.3. Tunneling with IPSec Tunneling has been defined in Section 5.1.2.1 of [RFC4301]. Upon encapsulation, the ECN field of the inner header is copied to the ECN field of the outer header. Decapsulation works as for the full- functionality option described in Section 3.3.3.2. Tunneling with IPsec also requires that PCN re-mark the ECN field only to CE because any other information is not copied to the inner header upon decapsulation and is lost. In contrast to Section 3.3.3.2, with IPsec tunnels, CE marks of tunneled PCN-traffic remain visible for routers along the tunnel and to their meters, markers, and droppers. 3.3.3.4. ECN Tunneling New tunneling rules for ECN are specified in [RFC6040], which updates [RFC3168] and [RFC4301]. These rules provide a consistent and rational approach to encapsulation and decapsulation. With the normal mode, the ECN field of the inner header is copied to the ECN field of the outer header on encapsulation. In compatibility mode, the ECN field of the outer header is reset to Not-ECT. Karagiannis, et al. Informational [Page 13]
RFC 6627 Pre-Congestion Notification Encoding July 2012 Upon decapsulation, the scheme specified in [RFC6040] and shown in Figure 6 is applied. Thus, re-marking encapsulated Not-ECT packets to any other codepoint would not survive decapsulation. Therefore, Not-ECT cannot be used for PCN encoding. Furthermore, re-marking encapsulated ECT(0) packets to ECT(1) or CE survives decapsulation, but not vice-versa, and re-marking encapsulated ECT(1) packets to CE also survives decapsulation, but not vice-versa. Certain combinations of inner and outer ECN fields cannot result from any transition in any current or previous ECN tunneling specification. These currently unused (CU) combinations are indicated in Figure 6 by '(!!!)' or '(!)'; where '(!!!)' means the combination is CU and always potentially dangerous, while '(!)' means it is CU and possibly dangerous. +---------+------------------------------------------------+ |Arriving | Arriving Outer Header | | Inner +---------+------------+------------+------------+ | Header | Not-ECT | ECT(0) | ECT(1) | CE | +---------+---------+------------+------------+------------+ | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)| | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | | ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE | | CE | CE | CE | CE(!!!)| CE | +---------+---------+------------+------------+------------+ The ECN field in the outgoing header is set to the codepoint at the intersection of the appropriate arriving inner header (row) and arriving outer header (column), or the packet is dropped where indicated. Currently unused combinations are indicated by '(!!!)' or '(!)'. ([RFC6040]; '(!!!)' means the combination is CU and always potentially dangerous, while '(!)' means it is CU and possibly dangerous.) Figure 6: New IP in IP Decapsulation Behavior (from [RFC6040]) 3.3.4. Restoration of the Original ECN Field at the PCN-Egress-Node As ECN is an end-to-end service, it is desirable that the egress node of a PCN-domain restore the ECN field that a PCN-packet had at the ingress node. There are basically two options. PCN-traffic may be tunneled between ingress and egress node using limited functionality tunnels (see Section 3.3.3.1). Then, PCN-marking is applied only to the outer header, and the original ECN field is restored after decapsulation. However, this reduces the MTU from the perspective of the user. Another option is to use some intelligent encoding that preserves the ECN codepoints. However, a viable solution is not known. Karagiannis, et al. Informational [Page 14]
RFC 6627 Pre-Congestion Notification Encoding July 2012 4. Comparison of Encoding Options The PCN working group has studied four different PCN encodings, which redefine the ECN field. Figure 7 summarizes these PCN encodings. One, or at most two, different DSCPs are used to indicate PCN- traffic, and, only for these DSCPs, the semantics of the ECN field are redefined within the PCN-domain. When a PCN-ingress-node classifies a packet as a PCN-packet, it sets its PCN-codepoint to not-marked (NM). Non-PCN-traffic can also use the PCN-specific DSCP by setting the Not-PCN codepoint. Special per- hop behavior, defined in [RFC5670], applies to PCN-traffic. ----------------------------------------------------------------------- | ECN Bits || 00 | 10 | 01 | 11 || DSCP | |==============++==========+==========+==========+==========++=========| | RFC 3168 || Not-ECT | ECT(0) | ECT(1) | CE || Any | |==============++==========+==========+==========+==========++=========| | Baseline || Not-PCN | NM | EXP | PM || PCN-n | |==============++==========+==========+==========+==========++=========| | 3-In-1 || Not-PCN | NM | ThM | ETM || PCN-n | |==============++==========+==========+==========+==========++=========| | 3-In-2 || Not-PCN | NM | CU | ThM || PCN-n | | ||----------+----------+----------+----------++---------| | || Not-PCN | CU | CU | ETM || PCN-m | |==============++==========+==========+==========+==========++=========| | PSDM || Not-PCN | Not-ETM | Not-ThM | PM || PCN-n | ----------------------------------------------------------------------- Notes: PCN-n, PCN-m under the DSCP column denotes PCN-compatible DSCPs, which may be chosen by the network operator. Not-PCN means that packets are not PCN-enabled. NM means not-marked. CU means currently unused. Figure 7: Semantics of the ECN Field for Various Encoding Types 4.1. Baseline Encoding With baseline encoding [RFC5696], the NM codepoint can be re-marked only to PCN-marked (PM). Excess-traffic-marking uses PM as ETM, threshold-marking uses PM as ThM, and only one of the two marking schemes can be used. So, baseline encoding supports SM-PCN. The 01-codepoint is reserved for experimental purposes (EXP) and the other defined PCN encoding schemes can be seen as extensions of baseline encoding by appropriate redefinition of EXP. Baseline encoding [RFC5696] works well with IPsec tunnels (see Section 3.3.3.3). Karagiannis, et al. Informational [Page 15]
RFC 6627 Pre-Congestion Notification Encoding July 2012 4.2. Encoding with 1 DSCP Providing 3 States PCN 3-state encoding uses a single DSCP (3-in-1 encoding, [RFC6660]), extends the baseline encoding, and supports the simultaneous use of both excess-traffic-marking and threshold-marking. 3-in-1 encoding well supports the preferred CL-PCN and also SM-PCN. The problem with 3-in-1 encoding is that the 10-codepoint does not survive decapsulation with the tunneling options in Sections 3.3.3.1 - 3.3.3.3. Therefore, the full 3-in-1 encoding may only be used for PCN-domains implementing the new rules for ECN tunnelling [RFC6040] or for PCN- domains without tunnels. Currently, it is not clear how fast the new tunnelling rules will be deployed and this affects the applicability of the full 3-in-1 encoding. Where PCN-domains do contain legacy tunnel endpoints, a restricted subset of the full 3-in-1 encoding can be used that omits the '01' codepoint. 4.3. Encoding with 2 DSCPs Providing 3 or More States PCN encoding using 2 DSCPs to provide 3 or more states (3-in-2 encoding, [PCN-3-in-2]) uses two different DSCPs to accommodate the three required codepoints NM, ThM, and ETM. It leaves some codepoints currently unused (CU), and also proposes a way to reuse them to store some information about the content of the ECN field before the packet enters the PCN-domain. 3-in-2 encoding works well with IPsec tunnels (see Section 3.3.3.3). This type of encoding can support both CL-PCN and SM-PCN schemes. The disadvantage of 3-in-2 encoding is that it consumes two DSCPs. Further, if PCN is applied to more than one Diffserv traffic class, then two DSCPs are needed for each. Moreover, the direct application of this encoding scheme to other technologies like MPLS, where even fewer bits are available for the encoding of DSCPs, is more difficult. 4.4. Encoding for Packet-Specific Dual Marking (PSDM) PCN encoding for packet-specific dual marking (PSDM) is designed to support PSDM-PCN outlined in Section 2.2.3. It is the only proposal that supports PCN-based AC and FT with only a single DSCP [PCN-PSDM] in the presence of IPsec tunnels (see Section 3.3.3.3). PSDM encoding also supports SM-PCN. Karagiannis, et al. Informational [Page 16]
RFC 6627 Pre-Congestion Notification Encoding July 2012 4.5. Standardized Encodings The baseline encoding described in Section 4.1 is defined in [RFC5696]. The intention was to allow for experimental encodings to build upon this baseline. However, following the publication of [RFC6040], the working group decided to change its approach and instead standardize only one encoding (the 3-in-1 encoding [RFC6660] described in Section 4.2). Rather than defining the 3-in-1 encoding as a Standards Track extension to the existing baseline encoding [RFC5696], it was agreed that it is best to define a new Standards Track document that obsoletes [RFC5696]. 5. Conclusion This document summarizes the PCN working group's exploration of a number of approaches for encoding pre-congestion information into the IP header. It is presented as an informational archive. It provides details of those approaches along with an explanation of the constraints that apply. The working group has concluded that the "3-in-1" encoding should be published as a Standards Track RFC that obsoletes the encoding specified in [RFC5696]. The reasoning is as follows. During the early life of the working group, the working group decided on an approach of a standardized "baseline" encoding [RFC5696], plus a series of experimental encodings that would all build on the baseline encoding, each of which would be useful in specific circumstances. However, after the tunneling of ECN was standardized in [RFC6040], the PCN working group decided on a different approach -- to recommend just one encoding, the "3-in-1 encoding". Although in theory "3-in-1" could be specified as a Standards Track extension to the "baseline" encoding, the working group decided that it would be cleaner to obsolete [RFC5696] and specify "3-in-1" encoding in a new, stand-alone RFC. 6. Security Implications [RFC5559] provides a general description of the security considerations for PCN. This memo does not introduce additional security considerations. 7. Acknowledgements We would like to acknowledge the members of the PCN working group and Gorry Fairhust for the discussions that generated and improved the contents of this memo. Karagiannis, et al. Informational [Page 17]
RFC 6627 Pre-Congestion Notification Encoding July 2012 8. References 8.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, November 2006. 8.2. Informative References [PCN-MS-AC] Menth, M. and R. Geib, "Admission Control Using PCN- Marked Signaling", Work in Progress, February 2011. [PCN-3-in-2] Briscoe, B., Moncaster, T., and M. Menth, "A PCN Encoding Using 2 DSCPs to Provide 3 or More States", Work in Progress, March 2012. [PCN-PSDM] Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, "PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding)", Work in Progress, March 2012. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003. Karagiannis, et al. Informational [Page 18]
RFC 6627 Pre-Congestion Notification Encoding July 2012 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009. [RFC5670] Eardley, P., Ed., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009. [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009. [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010. [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, July 2012. [RFC6661] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation", RFC 6661, July 2012. [RFC6662] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. Taylor, "Pre-Congestion Notification (PCN) Boundary- Node Behavior for the Single Marking (SM) Mode of Operation", RFC 6662, July 2012. [Menth09] Menth, M., Babiarz, J., and P. Eardley, "Pre-Congestion Notification Using Packet-Specific Dual Marking", IEEE Proceedings of the International Workshop on the Network of the Future (Future-Net), Dresden/Germany, June 2009. [Menth12] Menth, M. and F. Lehrieder, "Performance of PCN-Based Admission Control under Challenging Conditions", IEEE/ACM Transactions on Networking, vol. 20, no. 2, April 2012. [Menth10] Menth, M. and F. Lehrieder, "PCN-Based Measured Rate Termination", Computer Networks Journal, vol. 54, no. 3, Sept. 2010 Karagiannis, et al. Informational [Page 19]
RFC 6627 Pre-Congestion Notification Encoding July 2012
Authors' Addresses
Georgios Karagiannis
University of Twente
P.O. Box 217
7500 AE Enschede,
The Netherlands
EMail: g.karagiannis@utwente.nl
Kwok Ho Chan
Consultant
EMail: khchan.work@gmail.com
Toby Moncaster
University of Cambridge Computer Laboratory
William Gates Building, J J Thomson Avenue
Cambridge, CB3 0FD
United Kingdom
EMail: Toby.Moncaster@cl.cam.ac.uk
Michael Menth
University of Tuebingen
Sand 13
72076 Tuebingen
Germany
Phone: +49-7071-2970505
EMail: menth@uni-tuebingen.de
Philip Eardley
BT
B54/77, Sirius House Adastral Park Martlesham Heath
Ipswich, Suffolk IP5 3RE
United Kingdom
EMail: philip.eardley@bt.com
Bob Briscoe
BT
B54/77, Sirius House Adastral Park Martlesham Heath
Ipswich, Suffolk IP5 3RE
United Kingdom
EMail: bob.briscoe@bt.com
Karagiannis, et al. Informational [Page 20]
mirror server hosted at Truenetwork, Russian Federation.