Congestion and Pre-Congestion                                 B. Briscoe
Notification                                                          BT
Internet-Draft                                              T. Moncaster
Obsoletes: 5696 (if approved)              Moncaster Internet Consulting
Intended status: Standards Track           Moncaster Internet Consulting
Expires: November 22, 2011                                M. Menth
Expires: January 11, 2012                        University of Tuebingen
                                                            May 21,
                                                           July 10, 2011

       Encoding 3 PCN-States in the IP header using a single DSCP
                   draft-ietf-pcn-3-in-1-encoding-05
                   draft-ietf-pcn-3-in-1-encoding-06

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
   The overall rate of the PCN-traffic is metered, metered on every link in the
   PCN domain, and PCN-packets are appropriately marked when certain
   configured rates are exceeded.  Egress nodes provide decision points
   with pass information about the
   these PCN-marks of PCN-packets which allows them to take decisions about decision points which then decide whether to admit
   or block a new flow request,
   and requests or to terminate some already admitted already-admitted
   flows during serious pre-
   congestion. pre-congestion.

   This document specifies how PCN-marks are to be encoded into the IP
   header by re-using the Explicit Congestion Notification (ECN)
   codepoints within a PCN-domain.  This encoding builds on the baseline
   encoding of RFC5696 and provides for up to
   three different PCN marking states using a single DSCP: not-marked
   (NM), threshold-marked (ThM) and excess-traffic-marked (ETM).  Hence,
   it is called the 3-in-1 PCN encoding.  This document obsoletes
   RFC5696.

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 November 22, 2011. January 11, 2012.

Copyright Notice

   Copyright (c) 2011 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Changes in This Version (to be removed by RFC Editor)  . .  4
   2.
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Terminology  . . . . . .
     1.2.  Changes in This Version (to be removed by RFC Editor)  . .  5
   2.  Definitions and Abbreviations  . . . . . . . . . . . . . . .  5
   3.  Requirements for and Applicability of 3-in-1 PCN Encoding .  7
     2.1.  Terminology  .  5
     3.1.  PCN Requirements . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Requirements Imposed by Baseline Encoding .  7
     2.2.  List of Abbreviations  . . . . . . .  6
     3.3.  Applicability of 3-in-1 PCN Encoding . . . . . . . . . . .  7
   4.
   3.  Definition of 3-in-1 PCN Encoding  . . . . . . . . . . . . . .  7
   5.  Behaviour  8
   4.  Requirements for and Applicability of a PCN Node Compliant with the 3-in-1 PCN Encoding  . .  9
     4.1.  PCN Requirements . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Requirements Imposed by Tunnelling . . . .  8
   6.  Backward Compatibility . . . . . . . . .  9
     4.3.  Applicability of 3-in-1 PCN Encoding . . . . . . . . . . .  8
     6.1.  Backward Compatibility 10
   5.  Behaviour of a PCN-node to Comply with Pre-existing the 3-in-1 PCN
           Implementations  . . . . . . . .
       Encoding . . . . . . . . . . . . .  9
     6.2.  Recommendations for the Use of PCN Encoding Schemes . . .  9
       6.2.1.  Use of Both Excess-Traffic-Marking and
               Threshold-Marking . . . . . . . . . . . 10
     5.1.  PCN-ingress Node Behaviour . . . . . . . 10
       6.2.2.  Unique Use of Excess-Traffic-Marking . . . . . . . . . 10
       6.2.3.  Unique Use of Threshold-Marking
     5.2.  PCN-interior Node Behaviour  . . . . . . . . . . . 10
   7.  IANA Considerations . . . . 11
       5.2.1.  Behaviour Common to all PCN-interior Nodes . . . . . . 11
       5.2.2.  Behaviour of PCN-interior Nodes Using Two
               PCN-markings . . . . . . . . . . . 10
   8.  Security Considerations . . . . . . . . . . 11
       5.2.3.  Behaviour of PCN-interior Nodes Using One
               PCN-marking  . . . . . . . . . 10
   9.  Conclusions . . . . . . . . . . . . 11
     5.3.  Behaviour of PCN-egress Nodes  . . . . . . . . . . . . . 11
   10. Acknowledgements . 12
   6.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Backward Compatibility with ECN  . . 11
   11. Comments Solicited . . . . . . . . . . . 13
     6.2.  Backward Compatibility with the Baseline Encoding  . . . . 13
   7.  IANA Considerations  . . . . . . . 11 . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 15
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 15
     12.2. Informative References . . . . . . . . . . . . . . . . . . 12 15
   Appendix A.  Choice of Suitable DSCPs  . . . . . . . . . . . . . . 16
   Appendix B.  Co-existence of ECN and PCN (informative) . . . . . . 13 . . . . . . . 18
   Appendix C.  Example Mapping between Encoding of PCN-Marks in
                IP and in MPLS Shim Headers . . . . . . . . . . . . . 20
   Appendix D.  Rationale for different behaviours for single
                marking schemes . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 21

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 providing notification to boundary nodes about overloads
   before any real congestion occurs (hence "pre-congestion
   notification").

   [RFC5670] provides for two metering and marking functions that are
   generally configured with different reference rates.  Threshold-marking  Threshold-
   marking marks all PCN packets once their traffic rate on a link
   exceeds the configured reference rate (PCN-threshold-rate).  Excess-traffic-marking  Excess-
   traffic-marking marks only those PCN packets that exceed the
   configured reference rate (PCN-excess-rate).  The PCN-excess-rate is
   typically larger than the PCN-threshold-rate [RFC5559].  Egress nodes
   monitor the PCN-marks of received PCN-packets and provide pass information
   about the these PCN-marks to decision points which take decisions about flow admission and
   termination on this basis then decide whether to
   admit new flows or terminate existing flows
   [I-D.ietf-pcn-cl-edge-behaviour], [I-D.ietf-pcn-sm-edge-behaviour].

   The baseline encoding defined in [RFC5696] describes described how two PCN
   marking states (Not-marked and PCN-Marked) can could be encoded into the
   IP header using a single Diffserv codepoint.  It also provides provided an
   experimental codepoint (EXP), along with guidelines for the use of
   that codepoint.  To
   support the application of two different  Two PCN marking algorithms in a PCN-
   domain, states are sufficient for example as required in [I-D.ietf-pcn-cl-edge-behaviour], the Single
   Marking edge behaviour [I-D.ietf-pcn-sm-edge-behaviour].  However,
   PCN-domains utilising the controlled load edge behaviour
   [I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states are needed. states.
   This document describes an
   extension to extends the baseline encoding that uses by redefining the EXP
   codepoint to provide a third PCN marking state in the IP header,
   still using a single Diffserv codepoint.  This encoding scheme is
   therefore called the "3-in-1 PCN encoding".  It obsoletes the
   baseline encoding [RFC5696], which provides only a sub-set of the
   same capabilities.

   The full version of this encoding requires any tunnel endpoint within
   the PCN-domain to support the normal tunnelling rules defined in
   [RFC6040].  There is one limited exception to this constraint where
   the PCN-domain only uses the excess-traffic-marking behaviour and
   where the threshold-marking behaviour is deactivated.  This is
   discussed in Section 5.2.3.1.

   This document only concerns the PCN wire protocol encoding for all IP
   headers, whether IPv4 or IPv6.  It makes no changes or
   recommendations concerning algorithms for congestion marking or
   congestion response.  Other documents will define the PCN wire
   protocol for other header types.  For example, the MPLS encoding is defined in
   [RFC5129] and  Appendix A of that document provides an informative
   example for C discusses a possible
   mapping between the encodings in IP and in MPLS.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Changes in This Version (to be removed by RFC Editor)

   From draft-ietf-pcn-3-in-1-encoding-05 to -06:

      *  Draft re-written to obsolete baseline encoding [RFC5696].

      *  New section defining utilising this encoding for single
         marking.  Added an appendix explaining an apparent
         inconsistency relating to single marking.

      *  Moved (and updated) informative appendixes from [RFC5696] to
         this document.  Original Appendix C was omitted as it is now
         redundant.

      *  Significant re-structuring of document.

   From draft-ietf-pcn-3-in-1-encoding-04 to -05:

      *  Draft moved to standards track as per working group
         discussions.

      *  Added Appendix A B discussing ECN handling in the PCN-domain.

      *  Clarified that this document modifies [RFC5696].

      *  .......

   From draft-ietf-pcn-3-in-1-encoding-03 to -04:

      *  Updated document to reflect RFC6040.

      *  Re-wrote introduction.

      *  Re-wrote section on applicability.

      *  Re-wrote section on choosing encoding scheme.

      *  Updated author details.

   From draft-ietf-pcn-3-in-1-encoding-02 to -03:

      *  Corrected mistakes in introduction and improved overall
         readability.

      *  Added new terminology.

      *  Rewrote a good part of Section 4 and 5 to achieve more clarity.

      *  Added appendix explaining when to use which encoding scheme and
         how to encode them in MPLS shim headers.

      *  Added new co-author.

   From draft-ietf-pcn-3-in-1-encoding-01 to -02:

      *  Corrected mistake in introduction, which wrongly stated that
         the threshold-traffic rate is higher than the excess-traffic
         rate.  Other minor corrections.

      *  Updated acks & refs.

   From draft-ietf-pcn-3-in-1-encoding-00 to -01:

      *  Altered the wording to make sense if
         draft-ietf-tsvwg-ecn-tunnel moves to proposed standard.

      *  References updated

   From draft-briscoe-pcn-3-in-1-encoding-00 to
   draft-ietf-pcn-3-in-1-encoding-00:

      *  Filename changed to draft-ietf-pcn-3-in-1-encoding.

      *  Introduction altered to include new template description of
         PCN.

      *  References updated.

      *  Terminology brought into line with [RFC5670].

      *  Minor corrections.

2.  Requirements Language  Definitions and Abbreviations

2.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node,
   PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and "OPTIONAL" in this
   document PCN-
   marking are to be interpreted used as described in [RFC2119].

2.1.  Terminology

   General PCN-related terminology is defined in the PCN architecture
   [RFC5559], and terminology specific to packet encoding is [RFC5559].  The following additional
   terms are defined in
   the PCN baseline encoding [RFC5696].  Additional terminology is
   defined below. this document:

   PCN encoding:  mapping of PCN marking states to specific codepoints
      in the packet header.

3.  Requirements

   PCN-compatible Diffserv codepoint:  a Diffserv codepoint indicating
      packets for and Applicability of 3-in-1 PCN Encoding

3.1.  PCN Requirements

   In accordance with which the PCN architecture [RFC5559], PCN-ingress-nodes
   control packets entering a PCN-domain.  Packets belonging to PCN-
   controlled flows are subject ECN field is used to PCN-metering and -marking, and PCN-
   ingress-nodes mark them as Not-marked (PCN-colouring).  Any node in
   the PCN-domain may perform PCN-metering and -marking and mark PCN-
   packets if needed.  There are two different metering and marking
   schemes: threshold-marking and excess-traffic-marking [RFC5670].
   Some edge behaviors require only carry PCN-markings
      rather than [RFC3168] markings (see Appendix A).

   Threshold-marked codepoint:  a single marking scheme
   [I-D.ietf-pcn-sm-edge-behaviour], others require both
   [I-D.ietf-pcn-cl-edge-behaviour].  In the latter case, three PCN
   marking states are needed: not-marked (NM) to indicate not-marked
   packets, threshold-marked (ThM) to indicate codepoint that indicates packets that
      have been marked by at a PCN-interior-node as a result of an
      indication from the
   threshold-marker, and excess-traffic-marked (ETM) threshold-metering function [RFC5670].
      Abbreviated to indicate ThM.

   Excess-traffic-marked codepoint:  a codepoint that indicates packets
      that have been marked by at a PCN-interior-node as a result of an
      indication from the excess-traffic-marker excess-traffic-metering function [RFC5670].  Threshold-marking and
   excess-traffic-marking are configured
      Abbreviated to start marking packets at
   different load conditions, so one marking scheme indicates more
   severe pre-congestion than the other.  Therefore, ETM.

   Not-marked codepoint:  a fourth PCN
   marking state indicating codepoint that a packet is marked by both markers is indicates PCN-packets but
      that are not needed.  However PCN-marked.  Abbreviated to NM.

   not-PCN codepoint:  a fourth codepoint is required to indicate that indicates packets that are not PCN-capable (the not-PCN codepoint).

   In all current PCN edge behaviors that use two marking schemes
   [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking
   is configured with a larger reference rate than threshold-marking.
   We take this as a rule and define excess-traffic-marked as a more
   severe PCN-mark than threshold-marked.

3.2.  Requirements Imposed by Baseline Encoding
      PCN-packets.

2.2.  List of Abbreviations

   The baseline encoding scheme [RFC5696] was defined so that it could
   be extended to accommodate an additional marking state.  It provides
   rules to embed the encoding following abbreviations are used in this document:

   o  AF = Assured Forwarding [RFC2597]

   o  CE = Congestion Experienced [RFC3168]

   o  CS = Class Selector [RFC2474]

   o  DSCP = Diffserv codepoint

   o  ECN = Explicit Congestion Notification [RFC3168]

   o  ECT = ECN Capable Transport [RFC3168]
   o  EF = Expedited Forwarding [RFC3246]

   o  ETM = Excess-traffic-marked

   o  EXP = Experimental

   o  IP = Internet protocol

   o  NM = Not-marked

   o  PCN = Pre-Congestion Notification

   o  ThM = Threshold-marked

3.  Definition of two 3-in-1 PCN Encoding

   The 3-in-1 PCN encoding scheme allows for two or three PCN-marking
   states in to be encoded within the IP header.  The full encoding is
   shown in Figure 1 shows the structure of the former type-of-service field.  It
   contains the 6-bit Differentiated Services (DS) field that holds the
   DS codepoint (DSCP) [RFC2474] and the 2-bit 1.

   +--------+----------------------------------------------------+
   |        |           Codepoint in ECN field [RFC3168].

            0     1     2     3     4     5     6     7
         +-----+-----+-----+-----+-----+-----+-----+-----+ of IP header      |              DS FIELD
   | ECN FIELD  DSCP  |               <RFC3168 codepoint name>             |
   |        +--------------+-------------+-------------+---------+
   |        | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
   +--------+--------------+-------------+-------------+---------+
   | DSCP n |
         +-----+-----+-----+-----+-----+-----+-----+-----+    Not-PCN   |      NM     |     ThM     |   ETM   |
   +--------+--------------+-------------+-------------+---------+

                       Figure 1: Structure 3-in-1 PCN Encoding

   As mentioned above, the 3-in-1 PCN encoding is an extension of the former type-of-service field in IP

   Baseline
   baseline encoding defines that [RFC5696].  Like the DSCP must be set to baseline encoding it uses a PCN-
   compatible
   combination of a PCN-compatible DSCP (DSCP n in Figure 1) and the ECN-field [RFC3168] indicates ECN
   field for the specific
   PCN-mark.  Baseline encoding offers four possible encoding states
   within a single DSCP with of PCN-marks.  Appendix A discusses the choice
   of suitable DSCPs.  The PCN-marks have the following restrictions.

   o  Codepoint `00' (not-ECT) meaning.

   Not-PCN:  indicates a non-PCN-packet, i.e., a packet that is used not
      subject to indicate non-PCN traffic as
      "not-PCN".  This allows both PCN metering and non-PCN traffic to use the
      same DSCP.

   o  Codepoint `10' (ECT(0)) is used to indicate Not-marked PCN
      traffic.

   o  Codepoint `11' (CE) is used to indicate the most severe PCN-mark.

   o  Codepoint `01' (ECT(1)) is available marking.

   NM:  Not-marked.  Indicates a PCN-packet that has not yet been marked
      by any PCN marker.

   ThM:  Threshold-marked.  Indicates a PCN-packet that has been marked
      by a threshold-marker [RFC5670].

   ETM:  Excess-traffic-marked.  Indicates a PCN-packet that has been
      marked by an excess-traffic-marker [RFC5670].

4.  Requirements for experimental use and may
      be re-used by other Applicability of 3-in-1 PCN encodings such as Encoding

4.1.  PCN Requirements

   In accordance with the presently defined
      3-in-1 PCN encoding (subject architecture [RFC5559], PCN-ingress-nodes
   control packets entering a PCN-domain.  Packets belonging to the rules defined PCN-
   controlled flows are subject to PCN-metering and -marking, and PCN-
   ingress-nodes mark them as Not-marked (PCN-colouring).  Any node in [RFC5696]).

   [RFC6040] defines rules for
   the encapsulation PCN-domain may perform PCN-metering and decapsulation of
   ECN markings within IP-in-IP tunnels.  This RFC removes some of the
   constraints that existed when [RFC5696] was written.  Happily the
   rules for use of the EXP codepoint -marking and mark PCN-
   packets if needed.  There are fully compatible with
   [RFC6040]. two different metering and marking
   behaviours: threshold-marking and excess-traffic-marking [RFC5670].
   Some edge behaviors require only a single marking behaviour
   [I-D.ietf-pcn-sm-edge-behaviour], others require both
   [I-D.ietf-pcn-cl-edge-behaviour].  In particular, the relative severity of each latter case, three PCN
   marking is states are needed: not-marked (NM) to indicate not-marked
   packets, threshold-marked (ThM) to indicate packets marked by the same: CE (PM) is more severe than ECT(1) (EXP) is
   threshold-marker, and excess-traffic-marked (ETM) to indicate packets
   marked by the excess-traffic-marker [RFC5670].  Threshold-marking and
   excess-traffic-marking are configured to start marking packets at
   different load conditions, so one marking behaviour indicates more
   severe pre-congestion than ECT(0) (NM).  This the other.  Therefore, a fourth PCN
   marking state indicating that a packet is discussed in more detail in marked by both markers is
   not needed.  However a fourth codepoint is required to indicate
   packets that do not use PCN (the not-PCN codepoint).

   In all current PCN edge behaviors that use two marking behaviours
   [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking
   is configured with a larger reference rate than threshold-marking.
   We take this as a rule and define excess-traffic-marked as a more
   severe PCN-mark than threshold-marked.

4.2.  Requirements Imposed by Tunnelling

   [RFC6040] defines rules for the encapsulation and decapsulation of
   ECN markings within IP-in-IP tunnels.  The publication of RFC6040
   removed the tunnelling constraints that existed when the baseline
   encoding document [RFC5696] and was written (see section 3.3.2 of
   [I-D.ietf-pcn-encoding-comparison]).

   Nonetheless, there is still a problem if there are any legacy (pre-
   RFC6040) decapsulating tunnel endpoints within a PCN domain.  If a
   PCN node Threshold-marks the outer header of a tunnelled packet with
   a Not-marked codepoint on the inner header, the legacy decapsulator
   will revert the Threshold-marking to Not-marked.  The rules on
   applicability in
   [I-D.ietf-pcn-encoding-comparison].

3.3. Section 4.3 below are designed to avoid this
   problem.

4.3.  Applicability of 3-in-1 PCN Encoding

   The 3-in-1 encoding is applicable in situations where two marking
   schemes
   behaviours are being used in the PCN-domain.  In some circumstances it  The 3-in-1 encoding can
   also be used in PCN-domains with only a single one marking scheme behaviour, in
   use.  Further guidance on choosing an encoding scheme can which case one of
   the codepoints MUST NOT be found in used throughout the PCN-domain (see
   Section 6.2.  All nodes 5.2.3).

   For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP
   and IPsec) within the PCN-domain MUST be fully compliant comply with the ECN
   encapsulation and decapsulation rules set out in [RFC6040].  As [RFC6040] (see
   Section 4.2).  There is one exception to this rule outlined next.

   It may not be possible to upgrade every pre-RFC6040 tunnel endpoint
   within a PCN-domain.  In such cirsumstances a limited version of the
   3-in-1 encoding can still be used but only under the following
   stringent condition.  If any pre-RFC6040 tunnel endpoint exists
   within a PCN-domain then every PCN-node in the PCN-domain MUST be
   configured so that it never sets the ThM codepoint.  The behaviour of
   PCN-interior nodes in this case is not applicable defined in Section 5.2.3.1.  In
   all other situations where legacy tunnels tunnel endpoints might
   exist.

4.  Definition of 3-in-1 be present
   within the PCN Encoding

   The domain, the 3-in-1 PCN encoding scheme is an extension not applicable.

5.  Behaviour of a PCN-node to Comply with the baseline
   encoding scheme defined in [RFC5696].  The 3-in-1 PCN requirements and the
   extension rules for baseline encoding presented Encoding

   As mentioned in the previous
   section determine how PCN encoding states Section 4.3 above, all PCN-nodes MUST comply with
   [RFC6040].

5.1.  PCN-ingress Node Behaviour

   PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint.
   To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are carried
   already defined for use with admission-controlled traffic.
   Appendix A gives guidance to implementors on suitable DSCPs.
   Guidelines for mixing traffic types within a PCN-domain are given in
   [RFC5670].

   If a packet arrives at the IP
   headers.  This is shown in Figure 2.

         +--------+----------------------------------------------------+
         |        |           Codepoint in ECN field of IP header      |
         |  DSCP  |               <RFC3168 codepoint name>             |
         |        +--------------+-------------+-------------+---------+
         |        | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
         +--------+--------------+-------------+-------------+---------+
         | DSCP n |    Not-PCN   |      NM     |     ThM     |   ETM   |
         +--------+--------------+-------------+-------------+---------+
                       Figure 2: 3-in-1 PCN Encoding

   Like baseline encoding, 3-in-1 PCN encoding also uses PCN-ingress-node that shares a PCN PCN-
   compatible DSCP n and is not a PCN-packet, the PCN-ingress MUST mark it
   as not-PCN.

   If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress MUST
   change the PCN codepoint to Not-marked.

   If a PCN-packet arrives at the PCN-ingress-node with its ECN field for
   already set to a value other than not-ECT, then appropriate action
   MUST be taken to meet the encoding requirements of PCN-marks. [RFC4774].  The PCN-marks have the following meaning.

   Not-PCN:  indicates a non-PCN-packet, i.e., a packet that simplest
   appropriate action is not
      subject to PCN metering and marking.

   NM:  Not-marked.  Indicates just drop such packets.  However, this is a PCN-packet
   drastic action that has not yet been marked
      by any PCN marker.

   ThM:  Threshold-marked.  Indicates a PCN-packet that has been marked
      by a threshold-marker [RFC5670].

   ETM:  Excess-traffic-marked.  Indicates a PCN-packet that has been
      marked by an excess-traffic-marker [RFC5670].

5.  Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding

   To operator may feel is undesirable.  Appendix B
   provides more information and summarises other alternative actions
   that might be compliant with the 3-in-1 PCN Encoding, an PCN interior node
   behaves as follows:

   o  It taken.

5.2.  PCN-interior Node Behaviour

5.2.1.  Behaviour Common to all PCN-interior Nodes

   Interior nodes MUST NOT change not-PCN to any other codepoint.

   Interior nodes MUST NOT change NM to not-PCN.

   Interior nodes MUST NOT change ThM if to NM or not-PCN.

   Interior nodes MUST NOT change ETM to any other codepoint.

5.2.2.  Behaviour of PCN-interior Nodes Using Two PCN-markings

   If the threshold-meter function indicates a need to mark the packet;

   o  It packet,
   the PCN-interior node MUST change NM or ThM to ETM if ThM.

   If the excess-traffic-meter function indicates a need to mark the packet;
   packet:

   o  It  the PCN-interior node MUST NOT change not-PCN NM to NM, ThM, or ETM;

   o  It MUST NOT change a NM, ThM, or ETM to not-PCN;

   o  It MUST NOT change ThM to NM;

   o  It  the PCN-interior node MUST NOT change ETM to ThM or to NM;

   In other words, a PCN interior node MUST NOT mark PCN-packets into
   non-PCN packets and vice-versa, ETM.

   If both the threshold meter and it may increase the severity of excess-traffic meter indicate the PCN-mark of
   need to mark a PCN-packet, but it MUST NOT decrease it.

6.  Backward Compatibility

   Discussion of backward compatibility between PCN encoding schemes and
   previous uses of packet, the ECN field is given in Section 6 excess traffic marking rules MUST take
   priority.

5.2.3.  Behaviour of [RFC5696].

6.1.  Backward Compatibility with Pre-existing PCN-interior Nodes Using One PCN-marking

   Some PCN Implementations

   This encoding complies with the rules for extending edge behaviours require only one PCN-marking within the baseline PCN
   encoding schemes in Section 5 of [RFC5696]. PCN-
   domain.  The term "compatibility" is meant in Single Marking edge behaviour
   [I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark
   packets using the following sense. excess-traffic-meter function [RFC5670].  It is
   possible to operate nodes with baseline encoding [RFC5696] and 3-in-1
   encoding in that future schemes may require only the same PCN domain. threshold-meter
   function.  Observant readers may spot an apparent inconsistency
   between the two following cases.  Appendix D explains the rationale
   behind this inconsistency.

5.2.3.1.  Marking using only the Excess-traffic-meter Function

   The nodes with baseline encoding threshold-traffic-meter function SHOULD be disabled and MUST perform excess-traffic-marking because NOT
   trigger any packet marking.

   The PCN-interior node SHOULD raise a management alarm if it receives
   a ThM packet, but the 11 codepoint of
   3-in-1 encoding also means excess-traffic-marked.  PCN-boundary-nodes frequency of such domains are required to interpret alarms SHOULD be limited.

   If the full 3-in-1 encoding
   and not just baseline encoding, otherwise they cannot interpret excess-traffic-meter function indicates a need to mark the
   01 codepoint.

   Using nodes that perform only excess-traffic-marking may make sense
   in networks using
   packet:

   o  the CL edge behavior
   [I-D.ietf-pcn-cl-edge-behaviour].  Such nodes are able PCN-interior node MUST change NM to notify ETM;

   o  the
   egress only about severe pre-congestion when traffic needs PCN-interior node MUST change ThM to ETM.  It SHOULD also
      raise an alarm as above.

5.2.3.2.  Marking using only the Threshold-meter Function

   The excess-traffic-meter function SHOULD be
   terminated.  This seems reasonable for locations that are not
   expected to see disabled and MUST NOT
   trigger any pre-congestion, packet marking.

   The PCN-interior node SHOULD raise a management alarm if it receives
   an ETM packet, but excess-traffic-marking gives
   them the frequency of such alarms SHOULD be limited.

   If the threshold-meter function indicates a means need to terminate traffic if unexpected overload occurs.

6.2.  Recommendations for mark the packet:

   o  the PCN-interior node MUST change NM to ThM;

   o  the Use PCN-interior node MUST NOT change ETM to any other codepoint.
      It SHOULD raise an alarm as above.

5.3.  Behaviour of PCN Encoding Schemes

   NOTE: This sub-section PCN-egress Nodes

   A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all
   packets it forwards out of the PCN-domain.

   The only exception to this is informative not normative.

   When deciding which PCN encoding if the PCN-egress-node is suitable an operator needs certain that
   revealing other codepoints outside the PCN-domain won't contravene
   the guidance given in [RFC4774].  For instance, if the PCN-ingress-
   node has explicitly informed the PCN-egress-node that this flow is
   ECN-capable, then it might be safe to
   take account expose other codepoints.
   Appendix B gives details of how many PCN states need to be encoded.  The
   following table gives guidelines on which encoding to use with either
   threshold-marking, excess-traffic marking or both.

         +------------------------+--------------------------------+
         | Marking such schemes in use |  Recommended encoding scheme   |
         +------------------------+--------------------------------+
         | Only threshold-marking |   Baseline encoding [RFC5696]  |
         +------------------------+--------------------------------+
         | Only excess-traffic-   |   Baseline encoding [RFC5696]  |
         |       marking          |     or 3-in-1 PCN encoding     |
         +------------------------+--------------------------------+
         | Threshold-marking and  |     3-in-1 PCN encoding        |
         | excess-traffic-marking |                                |
         +------------------------+--------------------------------+

          Figure 3: Guidelines for choosing PCN encoding might work, but such
   schemes

6.2.1.  Use of Both Excess-Traffic-Marking and Threshold-Marking are currently experimental.

   If both excess-traffic-marking the PCN-domain is configured to use only excess-traffic marking,
   the PCN-egress node MUST treat ThM as ETM and threshold-marking are enabled in a
   PCN-domain, 3-in-1 encoding should be if only threshold-
   marking is used it should treat ETM as described ThM.  However it SHOULD raise
   a management alarm in either instance since this
   document.

6.2.2.  Unique Use of Excess-Traffic-Marking

   If only excess-traffic-marking means there is enabled some
   misconfiguration in the PCN-domain.

6.  Backward Compatibility

6.1.  Backward Compatibility with ECN

   BCP 124 [RFC4774] gives guidelines for specifying alternative
   semantics for the ECN field.  It sets out a PCN-domain, baseline
   encoding or 3-in-1 encoding may number of factors to be used.  They lead
   taken into consideration.  It also suggests various techniques to
   allow the same
   encoding because PCN-boundary nodes will interpret baseline "PCN-
   marked (PM)" as "excess-traffic-marked (ETM)".

6.2.3.  Unique Use co-existence of Threshold-Marking

   No scheme is currently proposed that solely default ECN and alternative ECN semantics.
   The encoding specified in this document uses threshold-marking.
   If such a scheme is proposed, the choice one of encoding scheme will
   depend on whether nodes are compliant with [RFC6040] or not.  Where those techniques;
   it defines PCN-compatible Diffserv codepoints as no longer supporting
   the default ECN semantics.  As such, this document is certain that all nodes in compatible with
   BCP 124.

   On its own, the PCN-domain are compliant then
   either 3-in-1 encoding or baseline encoding are suitable.  If legacy
   tunnel decapsulators exist cannot support both ECN marking end-
   to-end (e2e) and PCN-marking within the PCN-domain then baseline
   encoding SHOULD be used.

7.  IANA Considerations

   This memo includes no request a PCN-domain.  Appendix B
   discusses possible ways to do this, e.g. by carrying e2e ECN across a
   PCN-domain within the inner header of an IP-in-IP tunnel.  Although
   Appendix B recommends various approaches over others, it is merely
   informative and all such schemes are beyond the normative scope of
   this document.

   In any PCN deployment, traffic can only enter the PCN-domain through
   PCN-ingress-nodes and leave through PCN-egress-nodes.  PCN-ingress-
   nodes ensure that any packets entering the PCN-domain have the ECN
   field in their outermost IP header set to the appropriate PCN
   codepoint.  PCN-egress-nodes then guarantee that the ECN field of any
   packet leaving the PCN-domain has appropriate ECN semantics.  This
   prevents unintended leakage of ECN marks into or out of the PCN-
   domain, and thus reduces backward-compatibility issues.

6.2.  Backward Compatibility with the Baseline Encoding

   A PCN node implemented to use the obsoleted baseline encoding could
   conceivably have been configured so that the Threshold-meter function
   marked what is now defined as the ETM codepoint in the 3-in-1
   encoding.  However, thre is no known deployment of such an
   implementation and no reason to believe that such an implementation
   would ever have been built.  Therefore, it seems safe to ignore this
   issue.

7.  IANA Considerations

   This memo includes no request to IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

8.  Security Considerations

   The security concerns relating to this extended PCN encoding are

   PCN-marking only carries a meaning within the
   same as those in [RFC5696].  In summary, PCN-boundary nodes are
   responsible for ensuring inappropriate PCN markings do not leak into
   or out confines of a PCN domain, and the current phase PCN-
   domain.  This encoding document is intended to stand independently of
   the PCN architecture used to determine how specific packets are
   authorised to be PCN-marked, which will be described in separate
   documents on PCN-boundary-node behaviour.

   This document assumes that all the nodes of a PCN-domain are to be entirely under the control
   of a single operator, or a set of operators who trust each other.

   Given the only difference
   However, future extensions to PCN might include inter-domain versions
   where trust cannot be assumed between domains.  If such schemes are
   proposed, they must ensure that they can operate securely despite the baseline encoding and
   lack of trust.  However, such considerations are beyond the
   present 3-in-1 encoding scope of
   this document.

   One potential security concern is the use injection of spurious PCN-marks
   into the 01 codepoint, no new
   security issues are raised, as this codepoint was already available
   for experimental use PCN-domain.  However, these can only enter the domain if a
   PCN-ingress-node is misconfigured.  The precise impact of any such
   misconfiguration will depend on which of the proposed PCN-boundary-
   node behaviours is used, but in general spurious marks will lead to
   admitting fewer flows into the baseline encoding. domain or potentially terminating too
   many flows.  In either case, good management should be able to
   quickly spot the problem since the overall utilisation of the domain
   will rapidly fall.

9.  Conclusions

   The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field
   to encode PCN-marks.  One codepoint allows non-PCN traffic to be
   carried with the same PCN-compatible DSCP and three other codepoints
   support three PCN marking states with different levels of severity.
   The
   In general, the use of this PCN encoding scheme presupposes that any tunnels in
   tunnel endpoints within the PCN region have been updated to PCN-domain comply with [RFC6040].

10.  Acknowledgements

   Thanks

   Many thanks to Phil Eardley, Eardley for providing extensive feedback,
   critcism and advice.  Thanks also to Teco Boot, Kwok Ho Chan and Chan,
   Ruediger Geib, Georgios Karaginannis for reviewing this and everyone else who has
   commented on the document.

11.  Comments Solicited

   To be removed by RFC Editor: Comments and questions are encouraged
   and very welcome.  They can be addressed to the IETF Congestion and
   Pre-Congestion working group mailing list <pcn@ietf.org>, and/or to
   the authors.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [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.

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594,
              August 2006.

   [RFC5129]  Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
              Marking in MPLS", RFC 5129, January 2008.

   [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.

   [RFC5865]  Baker, F., Polk, J., and M. Dolly, "A Differentiated
              Services Code Point (DSCP) for Capacity-Admitted Traffic",
              RFC 5865, May 2010.

   [RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
              Notification", RFC 6040, November 2010.

12.2.  Informative References

   [I-D.ietf-pcn-cl-edge-behaviour]
              Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
              Taylor, "PCN Boundary Node Behaviour for the Controlled
              Load (CL) Mode of Operation",
              draft-ietf-pcn-cl-edge-behaviour-08
              draft-ietf-pcn-cl-edge-behaviour-09 (work in progress),
              December 2010.
              June 2011.

   [I-D.ietf-pcn-encoding-comparison]
              Karagiannis, G., Chan, K., Moncaster, T., Menth, M.,
              Eardley, P., and B. Briscoe, "Overview of Pre-Congestion
              Notification Encoding",
              draft-ietf-pcn-encoding-comparison-05
              draft-ietf-pcn-encoding-comparison-06 (work in progress),
              April
              June 2011.

   [I-D.ietf-pcn-sm-edge-behaviour]
              Charny, A., Karagiannis, G., Menth, M., and T. Taylor,
              "PCN Boundary Node Behaviour for the Single Marking (SM)
              Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-05 draft-ietf-pcn-sm-edge-behaviour-06
              (work in progress), December 2010.

Appendix A.  Co-existence of ECN June 2011.

   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and PCN (informative)

   The PCN encoding described in this document re-uses the bits of the
   ECN field in the IP header.  Consequently, this disables ECN within
   the PCN domain.  Appendix B of [RFC5696] included advice on handling
   ECN traffic within a PCN-domain.  This appendix clarifies that
   advice.

   For the purposes of this appendix J. Wroclawski,
              "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [RFC3246]  Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
              J., Courtney, W., Davari, S., Firoiu, V., and D.
              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
              Behavior)", RFC 3246, March 2002.

   [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
              Congestion Notification (ECN) Signaling with Nonces",
              RFC 3540, June 2003.

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594,
              August 2006.

   [RFC4774]  Floyd, S., "Specifying Alternate Semantics for the
              Explicit Congestion Notification (ECN) Field", BCP 124,
              RFC 4774, November 2006.

   [RFC5127]  Chan, K., Babiarz, J., and F. Baker, "Aggregation of
              DiffServ Service Classes", RFC 5127, February 2008.

   [RFC5129]  Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
              Marking in MPLS", RFC 5129, January 2008.

   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, February 2009.

   [RFC5696]  Moncaster, T., Briscoe, B., and M. Menth, "Baseline
              Encoding and Transport of Pre-Congestion Information",
              RFC 5696, November 2009.

   [RFC5865]  Baker, F., Polk, J., and M. Dolly, "A Differentiated
              Services Code Point (DSCP) for Capacity-Admitted Traffic",
              RFC 5865, May 2010.

Appendix A.  Choice of Suitable DSCPs

   This appendix is informative, not normative.

   The PCN working group chose not to define a single DSCP for use with
   PCN for several reasons.  Firstly, the PCN mechanism is applicable to
   a variety of different traffic classes.  Secondly, Standards Track
   DSCPs are in increasingly short supply.  Thirdly, PCN is not a
   scheduling behaviour -- rather, it should be seen as being a marking
   behaviour similar to ECN but intended for inelastic traffic.  The
   choice of which DSCP is most suitable for a given PCN-domain is
   dependent on the nature of the traffic entering that domain and the
   link rates of all the links making up that domain.  In PCN-domains
   with sufficient aggregation, the appropriate DSCPs would currently be
   those for the Real-Time Treatment Aggregate [RFC5127].  The PCN
   working group suggests using admission control for the following
   service classes (defined in [RFC4594]):

   o  Telephony (EF)

   o  Real-time interactive (CS4)

   o  Broadcast Video (CS3)

   o  Multimedia Conferencing (AF4)

   CS5 is excluded from this list since PCN is not expected to be
   applied to signalling traffic.  PCN can also be applied to the VOICE-
   ADMIT codepoint defined in [RFC5865].

   PCN-marking is intended to provide a scalable admission-control
   mechanism for traffic with a high degree of statistical multiplexing.
   PCN-marking would therefore be appropriate to apply to traffic in the
   above classes, but only within a PCN-domain containing sufficiently
   aggregated traffic.  In such cases, the above service classes may
   well all be subject to a single forwarding treatment (treatment
   aggregate [RFC5127]).  However, this does not imply all such IP
   traffic would necessarily be identified by one DSCP -- each service
   class might keep a distinct DSCP within the highly aggregated region
   [RFC5127].

   Additional service classes may be defined for which admission control
   is appropriate, whether through some future standards action or
   through local use by certain operators, e.g., the Multimedia
   Streaming service class (AF3).  This document does not preclude the
   use of PCN in more cases than those listed above.

   Note: The above discussion is informative not normative, as operators
   are ultimately free to decide whether to use admission control for
   certain service classes and whether to use PCN as their mechanism of
   choice.

Appendix B.  Co-existence of ECN and PCN

   This appendix is informative, not normative.

   The PCN encoding described in this document re-uses the bits of the
   ECN field in the IP header.  Consequently, this disables ECN within
   the PCN domain.  Appendix B of [RFC5696] (obsoleted) included advice
   on handling ECN traffic within a PCN-domain.  This appendix
   reiterates and clarifies that advice.

   For the purposes of this appendix we define two forms forms of traffic that
   might arrive at a PCN-ingress node.  These are Admission-controlled
   traffic and Non-admission-controlled traffic.

   Admission-controlled traffic will be remarked to a PCN-compatible
   DSCP by the PCN-ingress node.  Two mechanisms can be used to identify
   such traffic:

   a.  flow signalling associates a filterspec with a need for admission
       control (e.g. through RSVP or some equivalent message, e.g. from
       a SIP server to the ingress), and the PCN-ingress remarks traffic
       matching that filterspec to a PCN-compatible DSCP, as its chosen
       admission control mechanism.

   b.  Traffic arrives with a DSCP that implies it requires admission
       control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time,
       Broadcast TV when used for video on demand, and Multimedia
       Conferencing [RFC4594][RFC5865].

   All other traffic can be thought of as Non-admission-controlled (and
   therefore outside the scope of PCN).  However such traffic may still
   need to share the same DSCP as the Admission-controlled traffic.
   This may be due to policy (for instance if it is high priority voice
   traffic), or may be because there is a shortage of local DSCPs.

   ECN [RFC3168] is an end-to-end congestion notification mechanism.  As
   such it is possible that some traffic entering the PCN-domain may
   also be ECN capable.

   Unless specified otherwise, for any of the cases in the list below,
   an IP-in-IP tunnel can be used to preserve ECN markings across the
   PCN domain.  However the tunnelling action should be applied wholly
   outside the PCN-domain as illustrated in the following figure:

                ,  .  .  .  .  .  PCN-domain  .  .  .  .  .  .
               .   ,--------.                   ,--------.    .
              .   _|  PCN-   |___________________|  PCN-  |_   .
              .  / | ingress |                   | egress | \  .
               .|  '---------'                   '--------'  |.
                | .  .  .  .  .  .  .  .  .  .  .  .  .  .  .|
           ,--------.                                     ,--------.
     _____| Tunnel  |                                     | Tunnel |____
          | Ingress | - - ECN preserved inside tunnel - - | Egress |
          '---------'                                     '--------'

             Figure 2: Separation of tunneling and PCN actions

   There are four cases for how e2e ECN traffic may wish to be treated
   while crossing a PCN domain:

   ECN capable traffic that does not require admission control and does
   not carry a DSCP that the PCN-ingress is using for PCN-capable
   traffic.  This requires no action.

   ECN capable traffic that does not require admission control but
   carries a DSCP that the   PCN-ingress is using for PCN-capable
   traffic.  There are two options.

      *  The ingress maps the DSCP to a local DSCP with the same
         scheduling PHB as the original DSCP, and the egress re-maps it
         to the original PCN-compatible DSCP.

      *  The ingress tunnels the traffic, setting not-PCN in the outer
         header; note that this turns off ECN for this traffic within
         the PCN domain.

      The first option is recommended unless the operator is short of
      local DSCPs.

   ECN-capable Admission-controlled traffic:  There are two options.

      *  The PCN-ingress places this traffic that
   might arrive at in a tunnel with a PCN-
         compatible DSCP in the outer header.  The PCN-egress zeroes the
         ECN-field before decapsulation.

      *  The PCN-ingress node.  These are Admission-controlled
   traffic drops CE-marked packets and Non-admission-controlled traffic. the PCN-egress
         zeros the ECN field of all PCN packets.

      The second option is emphatically not recommended, unless perhaps
      as a last resort if tunnelling is not possible for some
      insurmountable reason.

   ECN-capable Admission-controlled traffic will be remarked where the e2e transport
   somehow indicates that it wants to see PCN marks:  NOTE this is
      currently tentative only.

      Schemes have been suggested where PCN marks may be leaked out of
      the PCN-compatible
   DSCP PCN-domain and used by the PCN-ingress node.  Two mechanisms can be used end hosts to identify modify realtime data
      rates.  Currently all such traffic:

   a.  flow signalling associates a filterspec schemes require further study and the
      following is for guidance only.

      The PCN-ingress needs to tunnel the traffic, taking care to comply
      with [RFC6040].  In this case the PCN-egress should not zero the
      ECN field, and then the [RFC6040] tunnel egress will preserve any
      PCN-marking.  Note that a need PCN interior node may turn ECT(0) into
      ECT(1), which would not be compatible with the (currently
      experimental) ECN nonce [RFC3540].

Appendix C.  Example Mapping between Encoding of PCN-Marks in IP and in
             MPLS Shim Headers

   This appendix is informative not normative.

   The 6 bits of the DS field in the IP header provide for admission
       control (e.g. through RSVP or some equivalent message down from a
       SIP server 64
   codepoints.  When encapsulating IP traffic in MPLS, it is useful to
   make the ingress), and DS field information accessible in the PCN-ingress remarks MPLS header.
   However, the MPLS shim header has only a 3-bit traffic
       matching that filterspec class (TC)
   field [RFC5462] providing for 8 codepoints.  The operator has the
   freedom to define a PCN-compatible DSCP, as its chosen
       admission control mechanism.

   b.  Traffic arrives with site-local mapping of a DSCP that implies it requires admission
       control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time,
       Broadcast TV when used for video on demand, and Multimedia
       Conferencing [RFC4594][RFC5865].

   All other traffic can be thought subset of as Non-admission-controlled.
   However such traffic may still need to share the same DSCP as 64
   codepoints of the
   Admission-controlled traffic.  This may be due DS field to policy (for
   instance if it is high priority voice traffic), or may be because
   there is a shortage of local DSCPs. the 8 codepoints in the TC field.

   [RFC5129] describes how ECN [RFC3168] is an end-to-end congestion notification mechanism.  As
   such it is possible that some traffic entering markings in the PCN-domain may IP header can also be ECN capable The following lists
   mapped to codepoints in the four cases for MPLS TC field.  Appendix A of [RFC5129]
   gives an informative description of how e2e
   ECN traffic may wish to be treated support PCN in MPLS by
   extending the way MPLS supports ECN.  But [RFC5129] was written while crossing
   PCN specifications were in early draft stages.  The following
   provides a clearer example of a mapping between PCN domain:

   ECN capable traffic that does not require admission control in IP and does
   not carry a DSCP that the PCN-ingress is in MPLS
   using for PCN-capable
   traffic.  This requires no action.

   ECN capable traffic the PCN terminology and concepts that does not require admission control but
   carries have since been
   specified.

   To support PCN in a DSCP that MPLS domain, codepoints for all used PCN-marks
   need to be provided in the  PCN-ingress TC field.  That means, when e.g. only
   excess-traffic-marking is using used for PCN-capable
   traffic.  There are two options.

      *  The ingress maps PCN purposes, the DSCP operator needs
   to define a local DSCP with the same
         scheduling PHB as the original DSCP, and the egress re-maps it site-local mapping to the original PCN-compatible DSCP.

      *  The ingress tunnels the traffic, setting not-PCN codepoints in the outer
         header; note that this turns off ECN MPLS TC field for this traffic within
         the PCN domain.

      The first option is recommended unless
   IP headers with:

   o  DSCP n and ECT(0)

   o  DSCP n and CE

   If both excess-traffic-marking and threshold-marking are used, the
   operator is short of
      local DSCPs.

   ECN-capable Admission-controlled traffic:  There are two options.

      *  The PCN-ingress places this traffic in a tunnel with needs to define a PCN-
         compatible DSCP site-local mapping to codepoints in the outer header.  The PCN-egress zeroes
   MPLS TC field for IP headers with all three of the
         ECN-field before decapsulation.

      *  The PCN-ingress drops CE-marked packets 3-in-1 codepoints:

   o  DSCP n and ECT(0)

   o  DSCP n and ECT(1)

   o  DSCP n and CE

   In either case, if the PCN-egress
         zeros operator wishes to support the ECN field of all same Diffserv
   PHB but without PCN packets.

      The second option is not recommended unless tunnelling is not
      possible for some reason..

   ECN-capable Admission-controlled where the e2e transport somehow
   indicates that marking, it wants will also be necessary to see PCN marks:  NOTE this is currently
      experimental only.

      Schemes have been suggested where PCN marks define a
   site-local mapping to an MPLS TC codepoint for IP headers marked
   with:

   o  DSCP n and Not-ECT

Appendix D.  Rationale for different behaviours for single marking
             schemes

   Readers may be leaked out of notice an apparent discrepancy between the PCN-domain two single
   marking behaviours in Section 5.2.3.1 and used by Section 5.2.3.2.  For the end hosts to modify realtime data
      rates.  Currently all such schemes are experimental and
   excess-traffic only marking an unexpected ThM marked packet is
   remarked as ETM.  For the
      following threshold only marking, an unexpected ETM
   marked packet is simply ignored (apart from an optional management
   alarm).

   There are two reasons for guidance only.

      The PCN-ingress needs to tunnel the traffic using [RFC6040].  The
      PCN-egress should not zero the ECN field, and having these seemingly contradictory
   requirements.  Firstly these behaviours conform with the tunnel egress
      should use [RFC6040] normal mode (preserving any PCN-marking).
      Note that this may turn ECT(0) into ECT(1) expected
   behaviour where both metering functions are being used for marking--
   ETM is always a more severe marking than ThM and so is not
      compatible with should never be
   re-marked.  Secondly the experimental ECN nonce [RFC3540].

   In threshold-metering behaviour in [RFC5670]
   uses the list above any form current marking state of IP-in-IP tunnel can the arriving packet to determine
   what action to take.  Consequently, in the ETM only marking it would
   be used unless
   specified otherwise.  NB, We assume a logical separation of tunneling
   and PCN actions potentially unsafe to allow ThM packets to propagate forward in both PCN-ingress and PCN-egress nodes.  That is,
   any tunneling action happens wholly outside
   the PCN-domain network as
   illustrated in they may adversely affect the following figure:

                ,  .  .  .  .  .  PCN-domain  .  .  .  .  .  .
               .   ,--------.                   ,--------.    .
              .   _|  PCN-   |___________________|  PCN-  |_   .
              .  / | ingress |                   | egress | \  .
               .|  '---------'                   '--------'  |.
                | .  .  .  .  .  .  .  .  .  .  .  .  .  .  .|
           ,--------.                                     ,--------.
     _____| Tunnel  |                                     | Tunnel |____
          | Ingress | - - ECN preserved inside tunnel - - | Egress |
          '---------'                                     '--------'

             Figure 4: Separation of tunneling and PCN actions threshold-metering
   function.

Authors' Addresses

   Bob Briscoe
   BT
   B54/77, Adastral Park
   Martlesham Heath
   Ipswich  IP5 3RE
   UK

   Phone: +44 1473 645196
   Email: bob.briscoe@bt.com
   URI:   http://bobbriscoe.net/

   Toby Moncaster
   Moncaster Internet Consulting
   Dukes
   Layer Marney
   Colchester  CO5 9UZ
   UK

   Phone: +44 7764 185416
   Email: toby@moncaster.com
   URI:   http://www.moncaster.com/

   Michael Menth
   University of Tuebingen
   Sand 13
   Tuebingen  72076
   Germany

   Phone: +49 7071 2970505
   Email: menth@informatik.uni-tuebingen.de