Internet DRAFT - draft-ietf-pcn-encoding-comparison
draft-ietf-pcn-encoding-comparison
PCN G. Karagiannis
Internet-Draft University of Twente
Intended status: Informational K. Chan
Expires: September 08, 2012 Consultant
T. Moncaster
University of Cambridge
M. Menth
University of Tuebingen
P. Eardley
B. Briscoe
BT
March 08, 2012
Overview of Pre-Congestion Notification Encoding
draft-ietf-pcn-encoding-comparison-09
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 the 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 which 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 all those approaches along with an explanation of
the constraints that had to be met by any solution.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 08, 2012.
Karagiannis, et al. Expires September 08, 2012 [Page 1]
Internet-Draft Pre-Congestion Notification Encoding March 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. Expires September 08, 2012 [Page 2]
Internet-Draft Pre-Congestion Notification Encoding March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. General PCN Encoding Requirements . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . 8
3.1. Structure of the DS Field . . . . . . . . . . . . . . . . 8
3.2. Constraints from the DSCP . . . . . . . . . . . . . . . . 8
3.2.1. General Scarcity of DSCPs . . . . . . . . . . . . . . 8
3.2.2. Handling of the DSCP in Tunneling Rules 9
3.2.3. Restoration of Original DSCPs at the Egress Node . . . 9
3.3. Constraints from the ECN Field . . . . . . . . . . . . . . 10
3.3.1. Structure and Use of the ECN Field . . . . . . . . . . 10
3.3.2. Redefinition of the ECN Field . . . . . . . . . . . . 10
3.3.3. Handling of the ECN Field in Tunneling Rules . . . . . 11
3.3.4. Restoration of the Original ECN Field at the
PCN-Egress-Node . . . . . . . . . . . . . . . . . . . 13
4. Comparison of Encoding Options . . . . . . . . . . . . . . . . 13
4.1. Baseline Encoding . . . . . . . . . . . . . . . . . . . . 14
4.2. Encoding with 1 DSCP Providing 3 States . . . . . . . . . 14
4.3. Encoding with 2 DSCPs Providing 3 or More States . . . . . 15
4.4. Encoding for Packet Specific Dual Marking (PSDM) . . . . . 15
4.5. Standardized Encodings . . . . . . . . . . . . . . . . . . 15
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Implications . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Karagiannis, et al. Expires September 08, 2012 [Page 3]
Internet-Draft Pre-Congestion Notification Encoding March 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, to decide whether to admit or
block a new flow request, and flow termination 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 decision points which take
decisions about flow admission and termination on this basis
[I-D.ietf-pcn-cl-edge-behaviour], [I-D.ietf-pcn-sm-edge-behaviour].
This PCN information has to be encoded into the IP header. 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 (version 4 and 6), already used codepoints must be re-used
which imposes additional constraints on design and applicability of
PCN-based admission control (AC) and flow termination (FT). This
document summarizes these issues as a record of the PCN WG
discussions and for the benefit of the wider IETF community.
In Section 2, we briefly point out PCN encoding requirement imposed
by metering and marking algorithms, and by special packet drop
strategies. The Differentiated Services Codepoint (6 bits) and the
ECN field (2 bits) have been selected to be re-used 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 supported by the PCN working group that allow
different implementations of PCN-based admission control and flow
termination 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.
Karagiannis, et al. Expires September 08, 2012 [Page 4]
Internet-Draft Pre-Congestion Notification Encoding March 2012
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 which are termed PCN-excess-rate
and PCN-threshold-rate, respectively. When traffic for PCN flows
enter a PCN domain, the PCN ingress node sets a codepoint in the IP
header indicating that the packet is subject to PCN metering and
marking and that it is not-marked (NM). The two metering and marking
algorithms possibly re-mark PCN packets as PCN and excess-traffic-
marked (ETM) or threshold-marked (ThM).
Excess-traffic-marking leaves a rate of PCN traffic equal to the PCN-
excess-rate to be not-ETM marked if possible. To that end, the
algorithm needs to know whether a PCN packet has already been ETM
marked 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 it needs it 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 rate is configured with
the PCN-admissible-rate (AR) and the PCN-supportable-rate (SR),
respectively. Threshold-marking meters all PCN traffic, but re-marks
only not-marked traffic (NM) to ThM. Excess-traffic-marking meters
only non-ETM traffic and re-marks either not-marked (NM) or
threshold-marked (ThM) PCN traffic 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.
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 [I-D.ietf-pcn-cl-edge-behaviour]. 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.
Karagiannis, et al. Expires September 08, 2012 [Page 5]
Internet-Draft Pre-Congestion Notification Encoding March 2012
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-ingress-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 [I-D.ietf-pcn-sm-edge-behaviour]. We briefly summarize
the concept. 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, requests the PCN-sent-rate from the
corresponding PCN-ingress-node, 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 has two major benefits: it 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.
Karagiannis, et al. Expires September 08, 2012 [Page 6]
Internet-Draft Pre-Congestion Notification Encoding March 2012
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] [Menth10q].
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 and the PCN-supportable-rate, 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 have the
same NM-marking and are distinguished 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.
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 [Menth09f]. We call
it PSDM-PCN. In contrast to CL-PCN and SM-PCN, AC is realized by re-
using marked signaling messages for probing. 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 traverses the PCN
domain and is re-marked, then the corresponding flow is blocked. This
is a light-weight probing mechanism which does not generate extra
traffic and does not introduce probing delay [draft-menth-pcn-marked-
signaling-ac]. 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.
Disadvantages of this approach are that every end-to-end signaling
protocol, e.g. RSVP, needs to be adapted that it denies admission if
initial request messages are re-marked to PM.
Advantages are that the AC algorithm is more accurate than the one of
CL-PCN and SM-PCN [Menth12], that only a single DSCP is needed,
and that the new tunneling rules in RFC6040 are not needed for
deployment.
Karagiannis, et al. Expires September 08, 2012 [Page 7]
Internet-Draft Pre-Congestion Notification Encoding March 2012
2.2.4. Preferential Packet Dropping
The termination algorithms described in [I-D.ietf-pcn-cl-edge
behaviour] and [I-D.ietf-pcn-sm-edge-behaviour] 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 [Menth10q]. Thus, preferential dropping
of ETM-marked packets is "RECOMMENDED" in [RFC5670]. As a
consequence, droppers must have access to the exact marking
information of PCN-packets.
3. Encoding Constraints
The PCN WG decided to use the DS field (i.e., combination of the DSCP
and ECN field) for the encoding of the PCN Marks, see [RFC5696].
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 field. [RFC0793]
defined the 8 bit ToS field and [RFC2474] redefined it as DS field.
It consists of a 6 bit DS codepoint (DSCP, see [RFC2474]) and the 2
bit ECN field (see [RFC3168]).
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | ECN |
+---+---+---+---+---+---+---+---+
DSCP: Differentiated Services codepoint [RFC2474]
ECN: ECN field [RFC3168]
Figure 4: The Structure of the DS Field
3.2. Constraints from the DSCP
The Differentiated Services codepoint (DSCP) 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 and requires a special DSCP that indicate 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
a single DSCP if possible, in any case not more than two DSCPs.
Therefore, the DSCP should be used to indicate that traffic is
subject to PCN metering and marking, but not to differentiate
different PCN markings.
Karagiannis, et al. Expires September 08, 2012 [Page 8]
Internet-Draft Pre-Congestion Notification Encoding March 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 and 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
Pseudo-Wires are potential solutions that scale well also in
backbone networks.
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.
Karagiannis, et al. Expires September 08, 2012 [Page 9]
Internet-Draft Pre-Congestion Notification Encoding March 2012
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 must be met
[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 sender
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].
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.
Karagiannis, et al. Expires September 08, 2012 [Page 10]
Internet-Draft Pre-Congestion Notification Encoding March 2012
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 re-use 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 contents 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 and 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 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.
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.
Karagiannis, et al. Expires September 08, 2012 [Page 11]
Internet-Draft Pre-Congestion Notification Encoding March 2012
This mode imposes the following constraints on PCN metering and
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 in Section 3.3.3.2. Tunneling with IPsec also
requires that PCN re-marks the ECN field only to CE because any other
information is not copied to the inner header upon decapsulation and
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.
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.
Karagiannis, et al. Expires September 08, 2012 [Page 12]
Internet-Draft Pre-Congestion Notification Encoding March 2012
+---------+------------------------------------------------+
|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 restores the ECN field 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.
4. Comparison of Encoding Options
The PCN WG 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 to be
sent with the PCN-specific DSCP, by setting the Not-PCN codepoint.
Special per hop behavior, defined in [RFC5670], applies to PCN-
traffic.
Karagiannis, et al. Expires September 08, 2012 [Page 13]
Internet-Draft Pre-Congestion Notification Encoding March 2012
-----------------------------------------------------------------------
| 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 to signal a not-pre-
congested path. 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.
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).
4.2. Encoding with 1 DSCP Providing 3 States
PCN 3-state encoding extension in a single DSCP (3-in-1 encoding,
[I-D.ietf-pcn-3-in-1-encoding] 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 Section 3.3.3.1 -
3.3.3.3. Therefore, 3-in-1 encoding may be used only for PCN domains
implementing the new rules for ECN tunneling [RFC6040], see Section
3.3.3.4), or where it is known that there are no tunnels in the PCN
domain. Currently it is not clear how fast the new tunneling rules
will be deployed, but the applicability of 3-in-1-encoding depends on
that.
Karagiannis, et al. Expires September 08, 2012 [Page 14]
Internet-Draft Pre-Congestion Notification Encoding March 2012
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, [I-D.ietf-pcn-3-state-encoding] uses two different DSCPs to
accommodate the three required codepoints NM, ThM, and ETM. It
leaves some codepoints currently unused (CU) and proposes also one
way how to reuse them to store some information about the content of
the ECN field before the packet entered 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.
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
[I-D.ietf-pcn-psdm-encoding] in the presence of IPsec tunnels (see
Section 3.3.3.3). PSDM encoding also supports SM-PCN.
4.5. Standardized encodings
The baseline encoding described in section 4.1 was published as a
draft Internet Standard [RFC5696]. The intention was to allow for
experimental encodings to build upon this baseline. However,
following the publication of [RFC6040], the WG decided to change
approach and instead standardize only one encoding (the 3-in-1
encoding described in 4.2 [I-D.ietf-pcn-3-in-1-encoding]. Rather than
defining the 3-in-1 encoding as a standards track extension to the
existing baseline encoding [RFC5696], it was agreed that it was 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 all those approaches along with an explanation of the
constraints that have to be met. 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, we decided on an approach of a standardized "baseline
encoding" [RFC5696] plus a series of experimental encodings that
would all build on the baseline encoding and each of which would be
useful in specific circumstances. However, after the tunneling of
ECN was standardized in [RFC6040], the PCN WG decided on a different
approach - to recommend just one encoding, the "3-in-1 encoding".
Karagiannis, et al. Expires September 08, 2012 [Page 15]
Internet-Draft Pre-Congestion Notification Encoding March 2012
Although in theory "3-in-1" could be specified as a standards-track
extension to the "baseline" encoding, the WG 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. IANA Considerations
This memo includes no request to IANA.
8. 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.
9. References
9.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.
9.2. Informative References
[I-D.ietf-pcn-cl-edge-behaviour]
Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
Taylor, "PCN Boundary Node Behaviour for the Controlled
Load (CL) Mode of Operation",
draft-ietf-pcn-cl-edge-behaviour-12 (work in progress),
February 2012.
Karagiannis, et al. Expires September 08, 2012 [Page 16]
Internet-Draft Pre-Congestion Notification Encoding March 2012
[I-D.ietf-pcn-sm-edge-behaviour]
Charny, A., Karagiannis, G., Menth, M., and T. Taylor,
"PCN Boundary Node Behaviour for the Single Marking (SM)
Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-09
(work in progress), February 2012.
[I-D.ietf-pcn-3-in-1-encoding]
Briscoe, B., Moncaster, T., and M. Menth, "Encoding 3 PCN-
States in the IP header using a single DSCP",
draft-ietf-pcn-3-in-1-encoding-08 (work in progress),
August 2011.
[I-D.ietf-pcn-3-state-encoding]
Briscoe, B., Moncaster, T., and M. Menth, "A PCN encoding
using 2 DSCPs to provide 3 or more states",
draft-ietf-pcn-3-state-encoding-01 (work in progress),
February 2010.
[I-D.ietf-pcn-psdm-encoding]
Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe,
"PCN Encoding for Packet-Specific Dual Marking (PSDM
Encoding)", draft-ietf-pcn-psdm-encoding-01 (work in
progress), March 2010.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009.
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
Nodes", RFC 5670, November 2009.
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information",
RFC 5696, November 2009.
[Menth09f]
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) at Dresden Germany, June 2009.
Karagiannis, et al. Expires September 08, 2012 [Page 17]
Internet-Draft Pre-Congestion Notification Encoding March 2012
[Menth12]
Menth, M. and F. Lehrieder, " Performance of PCN-Based
Admission Control under Challenging Conditions", accepted
for publication IEEE/ACM Transactions on Networking in
2012.
[Menth10q]
Menth, M. and F. Lehrieder, "PCN-Based Measured Rate
Termination", Computer Networks Journal, vol. 54, no. 3,
Sept. 2010
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.
Email Toby.Moncaster@cl.cam.ac.uk
Michael Menth
Chair of Communication Networks
University of Tuebingen
Sand 13
72076 Tuebingen
Germany
Email: menth@informatik.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
Karagiannis, et al. Expires September 08, 2012 [Page 18]
Internet-Draft Pre-Congestion Notification Encoding March 2012
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. Expires September 08, 2012 [Page 19]
