doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc6627.txt b/doc/rfc/rfc6627.txt
new file mode 100644
index 0000000..97f0457
--- /dev/null
+++ b/doc/rfc/rfc6627.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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]
+