GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6660

Internet Engineering Task Force (IETF) B. Briscoe Request for Comments: 6660 BT Obsoletes: 5696 T. Moncaster Category: Standards Track University of Cambridge ISSN: 2070-1721 M. Menth

                                               University of Tuebingen
                                                             July 2012
      Encoding Three Pre-Congestion Notification (PCN) States
     in the IP Header Using a Single Diffserv Codepoint (DSCP)

Abstract

 The objective of Pre-Congestion Notification (PCN) is to protect the
 quality of service (QoS) of inelastic flows within a Diffserv domain.
 The overall rate of PCN-traffic is metered on every link in the PCN-
 domain, and PCN-packets are appropriately marked when certain
 configured rates are exceeded.  Egress nodes pass information about
 these PCN-marks to Decision Points that then decide whether to admit
 or block new flow requests or to terminate some already admitted
 flows during serious pre-congestion.
 This document specifies how PCN-marks are to be encoded into the IP
 header by reusing the Explicit Congestion Notification (ECN)
 codepoints within a PCN-domain.  The PCN wire protocol for non-IP
 protocol headers will need to be defined elsewhere.  Nonetheless,
 this document clarifies the PCN encoding for MPLS in an informational
 appendix.  The encoding for IP provides for up to three different PCN
 marking states using a single Diffserv codepoint (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
 RFC 5696.

Status of This Memo

 This is an Internet Standards Track document.
 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).  Further information on
 Internet Standards is available in 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/rfc6660.

Briscoe, et al. Standards Track [Page 1] RFC 6660 3-in-1 PCN 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.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
 2.  Definitions and Abbreviations  . . . . . . . . . . . . . . . .  4
   2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2.  List of Abbreviations  . . . . . . . . . . . . . . . . . .  5
 3.  Definition of 3-in-1 PCN Encoding  . . . . . . . . . . . . . .  6
 4.  Requirements for and Applicability of 3-in-1 PCN Encoding  . .  7
   4.1.  PCN Requirements . . . . . . . . . . . . . . . . . . . . .  7
   4.2.  Requirements Imposed by Tunnelling . . . . . . . . . . . .  7
   4.3.  Applicable Environments for the 3-in-1 PCN Encoding  . . .  8
 5.  Behaviour of a PCN-node to Comply with the 3-in-1 PCN
     Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.1.  PCN-Ingress-Node Behaviour . . . . . . . . . . . . . . . .  8
   5.2.  PCN-Interior-Node Behaviour  . . . . . . . . . . . . . . . 11
     5.2.1.  Behaviour Common to All PCN-Interior-Nodes . . . . . . 11
     5.2.2.  Behaviour of PCN-Interior-Nodes Using Two
             PCN-Markings . . . . . . . . . . . . . . . . . . . . . 11
     5.2.3.  Behaviour of PCN-Interior-Nodes Using One
             PCN-Marking  . . . . . . . . . . . . . . . . . . . . . 12
   5.3.  PCN-Egress-Node Behaviour  . . . . . . . . . . . . . . . . 13
 6.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13
   6.1.  Backward Compatibility with ECN  . . . . . . . . . . . . . 13
   6.2.  Backward Compatibility with the Encoding in RFC 5696 . . . 14
 7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
 8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 15
 9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
   10.2. Informative References . . . . . . . . . . . . . . . . . . 16
 Appendix A.  Choice of Suitable DSCPs  . . . . . . . . . . . . . . 18
 Appendix B.  Coexistence of ECN and PCN  . . . . . . . . . . . . . 19

Briscoe, et al. Standards Track [Page 2] RFC 6660 3-in-1 PCN Encoding July 2012

 Appendix C.  Example Mapping between Encoding of PCN-Marks in
              IP and in MPLS Shim Headers . . . . . . . . . . . . . 22
 Appendix D.  Rationale for Difference between the Schemes
              Using One PCN-Marking . . . . . . . . . . . . . . . . 23

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 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).  The PCN-excess-rate is
 typically larger than the PCN-threshold-rate [RFC5559].  Egress nodes
 monitor the PCN-marks of received PCN-packets and pass information
 about these PCN-marks to Decision Points that then decide whether to
 admit new flows or terminate existing flows [RFC6661] [RFC6662].
 The encoding defined in [RFC5696] described how two PCN marking
 states (not-marked and PCN-marked) could be encoded into the IP
 header using a single Diffserv codepoint.  It defined '01' as an
 experimental codepoint (EXP), along with guidelines for its use.  Two
 PCN marking states are sufficient for the Single Marking edge
 behaviour [RFC6662].  However, PCN-domains utilising the controlled
 load edge behaviour [RFC6661] require three PCN marking states.  This
 document extends the encoding that originally appeared in RFC 5696 by
 redefining the experimental codepoint as a third PCN marking state in
 the IP header, but still using a single Diffserv codepoint.  This
 encoding scheme is therefore called the "3-in-1 PCN encoding".  It
 obsoletes the [RFC5696] encoding, which provides only a subset of the
 same capabilities.
 The full version of the 3-in-1 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

Briscoe, et al. Standards Track [Page 3] RFC 6660 3-in-1 PCN Encoding July 2012

 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 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.  Appendix C discusses a possible
 mapping between IP and 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].

2. Definitions and Abbreviations

2.1. Terminology

 The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node,
 PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets, and
 PCN-marking are used as defined in [RFC5559].  The following
 additional terms are defined in this document:
 PCN encoding:  mapping of PCN marking states to specific codepoints
    in the packet header.
 PCN-compatible Diffserv codepoint:  a Diffserv codepoint indicating
    packets for which the ECN field carries PCN-markings rather than
    [RFC3168] markings.  Note that an operator configures PCN-nodes to
    recognise PCN-compatible DSCPs, whereas the same DSCP has no PCN-
    specific meaning to a node outside the PCN-domain.
 Threshold-marked codepoint:  a codepoint that indicates a packet has
    been threshold-marked; that is, a packet that has been marked at a
    PCN-interior-node as a result of an indication from the threshold-
    metering function [RFC5670].  Abbreviated to ThM codepoint.
 Excess-traffic-marked codepoint:  a codepoint that indicates packets
    that have been marked at a PCN-interior-node as a result of an
    indication from the excess-traffic-metering function [RFC5670].
    Abbreviated to ETM codepoint.
 Not-marked codepoint:  a codepoint that indicates PCN-packets that
    are not PCN-marked.  Abbreviated to NM codepoint.

Briscoe, et al. Standards Track [Page 4] RFC 6660 3-in-1 PCN Encoding July 2012

 Not-PCN codepoint:  a codepoint that indicates packets that are not
    PCN-packets.

2.2. List of Abbreviations

 The 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  e2e = end-to-end
 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  NM = not-marked
 o  PCN = Pre-Congestion Notification
 o  PHB = Per-hop behaviour [RFC2474]
 o  ThM = threshold-marked

Briscoe, et al. Standards Track [Page 5] RFC 6660 3-in-1 PCN Encoding July 2012

3. Definition of 3-in-1 PCN Encoding

 The 3-in-1 PCN encoding scheme supports networks that need three PCN-
 marking states to be encoded within the IP header, as well as those
 that need only two.  The full encoding is shown in Figure 1.
 +--------+----------------------------------------------------+
 |        |           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 1: 3-in-1 PCN Encoding
 A PCN-node will be configured to recognise certain DSCPs as PCN-
 compatible.  Appendix A discusses the choice of suitable DSCPs.  In
 Figure 1, 'DSCP n' indicates such a PCN-compatible DSCP.  In the PCN-
 domain, any packet carrying a PCN-compatible DSCP and with the ECN-
 field anything other than 00 (not-PCN) is a PCN-packet as defined in
 [RFC5559].
 PCN-nodes MUST interpret the ECN field of a PCN-packet using the
 3-in-1 PCN encoding, rather than [RFC3168].  This does not change the
 behaviour for any packet with a DSCP that is not PCN-compatible, or
 for any node outside a PCN-domain.  In all such cases, the 3-in-1
 encoding is not applicable, and so by default the node will interpret
 the ECN field using [RFC3168].
 When using the 3-in-1 encoding, the codepoints of the ECN field have
 the following meanings:
 not-PCN:  indicates a non-PCN-packet, i.e., a packet that uses a PCN-
    compatible DSCP but is not subject to PCN metering and 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].

Briscoe, et al. Standards Track [Page 6] RFC 6660 3-in-1 PCN Encoding July 2012

4. Requirements for and Applicability of 3-in-1 PCN Encoding

4.1. PCN Requirements

 In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes
 control packets entering a PCN-domain.  Packets belonging to PCN-
 controlled flows are subject to PCN-metering and PCN-marking, and
 PCN-ingress-nodes mark them as not-marked (PCN-colouring).  All nodes
 in the PCN-domain perform PCN-metering and PCN-mark PCN-packets if
 needed.  There are two different metering and marking behaviours:
 threshold-marking and excess-traffic-marking [RFC5670].  Some edge
 behaviours require only a Single Marking behaviour [RFC6662], others
 require both [RFC6661].  In the latter case, three PCN marking states
 are needed: not-marked (NM) to indicate not-marked packets,
 threshold-marked (ThM) to indicate packets marked by the 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 the other.  Therefore, a fourth PCN marking state
 indicating that a packet is marked by both markers is not needed.
 However, a fourth codepoint is required to indicate packets that use
 a PCN-compatible DSCP but do not use PCN-marking (the not-PCN
 codepoint).
 In all current PCN edge behaviours that use two marking behaviours
 [RFC5559] [RFC6661], 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 RFC 6040
 removed the tunnelling constraints that existed when the encoding of
 [RFC5696] was written (see Section 3.3.2 of [RFC6627]).
 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 that
 has a not-marked codepoint on the inner header, a legacy decapsulator
 will forward the packet as not-marked, losing the Threshold-marking.
 The rules on applicability in Section 4.3 below are designed to avoid
 this problem.

Briscoe, et al. Standards Track [Page 7] RFC 6660 3-in-1 PCN Encoding July 2012

 Even if an operator accidentally breaks these applicability rules,
 the order of severity of the 3-in-1 codepoints was chosen to protect
 other PCN or non-PCN traffic.  Although legacy pre-RFC6040 tunnels
 did not propagate '01', all tunnels pre-RFC6040 and post-RFC6040 have
 always propagated '11' correctly.  Therefore, '11' was chosen to
 signal the most severe pre-congestion (ETM), so it would act as a
 reliable fail-safe even if an overlooked legacy tunnel was
 suppressing '01' (ThM) signals.

4.3. Applicable Environments for the 3-in-1 PCN Encoding

 The 3-in-1 encoding is applicable in situations where two marking
 behaviours are being used in the PCN-domain.  The 3-in-1 encoding can
 also be used with only one marking behaviour, in which case one of
 the codepoints MUST NOT be used anywhere in the PCN-domain (see
 Section 5.2.3).
 With one exception (see next paragraph), any tunnel endpoints
 (IP-in-IP and IPsec) within the PCN-domain MUST comply with the ECN
 encapsulation and decapsulation rules set out in [RFC6040] (see
 Section 4.2).
 Operators may not be able to upgrade every pre-RFC6040 tunnel
 endpoint within a PCN-domain.  In such circumstances, a limited
 version of the 3-in-1 encoding can still be used but only under the
 following stringent condition.  If any pre-RFC6040 tunnel
 decapsulator exists within a PCN-domain, then every PCN-node in the
 PCN-domain MUST be configured so that it never sets the ThM
 codepoint.  PCN-interior-nodes in this case MUST solely use the
 Excess-traffic-marking function, as defined in Section 5.2.3.1.  In
 all other situations where legacy tunnel decapsulators might be
 present within the PCN-domain, the 3-in-1 encoding is not applicable.

5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding

 Any tunnel endpoint implementation on a PCN-node MUST comply with
 [RFC6040].  Since PCN is a new capability, this is considered a
 reasonable requirement.

5.1. PCN-Ingress-Node Behaviour

 If packets arrive from another Diffserv domain, any re-mapping of
 Diffserv codepoints MUST happen before PCN-ingress processing.
 At each logical ingress link into a PCN-domain, each PCN-ingress-node
 will apply the four functions described in Section 4.2 of [RFC5559]
 to arriving packets.  These functions are applied in the following
 order: PCN-classify, PCN-police, PCN-colour, PCN-rate-meter.  This

Briscoe, et al. Standards Track [Page 8] RFC 6660 3-in-1 PCN Encoding July 2012

 section describes these four steps, but only the aspects relevant to
 packet encoding:
 1. PCN-classification:  The PCN-ingress-node determines whether each
    packet matches the filter spec of an admitted flow.  Packets that
    match are defined as PCN-packets.
 1b. Extra step if ECN and PCN coexist:  If a packet classified as a
    PCN-packet arrives with the ECN field already set to a value other
    than Not-ECT (i.e., it is from an ECN-capable transport), then to
    comply with BCP 124 [RFC4774] it MUST pass through one of the
    following preparatory steps before the PCN-policing and PCN-
    colouring steps.  The choice between these four actions depends on
    local policy:
  • Encapsulate ECN-capable PCN-packets across the PCN-domain:
       +  either within another IP header using an RFC6040 tunnel;
       +  or within a lower-layer protocol capable of being PCN-
          marked, such as MPLS (see Appendix C).
       Encapsulation using either of these methods is the RECOMMENDED
       policy for ECN-capable PCN-packets, and implementations SHOULD
       use IP-in-IP tunnelling as the default.
       If encapsulation is used, it MUST precede PCN-policing and PCN-
       colouring so that the encapsulator and decapsulator are
       logically outside the PCN-domain (see Appendix B and
       specifically Figure 2).
       If MPLS encapsulation is used, note that penultimate hop
       popping [RFC3031] is incompatible with PCN, unless the
       penultimate hop applies the PCN-egress-node behaviour before it
       pops the PCN-capable MPLS label.
  • If some form of encapsulation is not possible, the PCN-ingress-

node can allow through ECN-capable packets without

       encapsulation, but it MUST drop CE-marked packets at this
       stage.  Failure to drop CE-marked packets would risk congestion
       collapse, because without encapsulation there is no mechanism
       to propagate the CE markings across the PCN-domain (see
       Appendix B).
       This policy is NOT RECOMMENDED because there is no tunnel to
       protect the e2e ECN capability, which is otherwise disabled
       when the PCN-egress-node zeroes the ECN field.

Briscoe, et al. Standards Track [Page 9] RFC 6660 3-in-1 PCN Encoding July 2012

  • Drop the packet.
       This policy is also NOT RECOMMENDED, because it precludes the
       possibility that e2e ECN can coexist with PCN as a means of
       controlling congestion.
  • Any other action that complies with [RFC4774] (see Appendix B

for an example).

    Appendix B provides more information about the coexistence of PCN
    and ECN.
 2. PCN-policing:  The PCN-policing function only allows appropriate
    packets into the PCN behaviour aggregate.  Per-flow policing
    actions may be required to block rejected flows and to rate-police
    accepted flows, but these are specified in the relevant edge-
    behaviour document, e.g., [RFC6662] or [RFC6661].
    Here, we only specify packet-level PCN-policing, which prevents
    packets that are not PCN-packets from being forwarded into the
    PCN-domain if PCN-interior-nodes would otherwise mistake them for
    PCN-packets.  A non-PCN-packet will be confused with a PCN-packet
    if on arrival it meets all three of the following conditions:
    a)  it is not classified as a PCN-packet;
    b)  it already carries a PCN-compatible DSCP; and
    c)  its ECN field carries a codepoint other than Not-ECT.
    The PCN-ingress-node MUST police packets that meet all three
    conditions (a-c) by subjecting them to one of the following
    treatments:
  • re-mark the DSCP to a DSCP that is not PCN-compatible;
  • tunnel the packet to the PCN-egress-node with a DSCP in the

outer header that is not PCN-compatible; or

  • drop the packet (NOT RECOMMENDED – see below).
    The choice between these actions depends on local policy.  In the
    absence of any operator-specific configuration for this case, an
    implementation SHOULD re-mark the DSCP to zero (000000) by
    default.

Briscoe, et al. Standards Track [Page 10] RFC 6660 3-in-1 PCN Encoding July 2012

    Whichever policing action is chosen, the PCN-ingress-node SHOULD
    log the event and MAY also raise an alarm.  Alarms SHOULD be rate-
    limited so that the anomalous packets will not amplify into a
    flood of alarm messages.
    Rationale: Traffic that meets all three of the above conditions
    (a-c) is not PCN-traffic; therefore, ideally a PCN-ingress ought
    not to interfere with it, but it has to do something to avoid
    ambiguous packet markings.  Clearing the ECN field is not an
    appropriate policing action, because a network node ought not to
    interfere with an e2e signal.  Even if such packets seem like an
    attack, drop would be overkill, because such an attack can be
    neutralised by just re-marking the DSCP.  And DSCP re-marking in
    the network is legitimate, because the DSCP is not considered an
    e2e signal.
 3. PCN-colouring:  If a packet has been classified as a PCN-packet,
    once it has been policed, the PCN-ingress-node:
  • MUST set a PCN-compatible Diffserv codepoint on all PCN-

packets. To conserve DSCPs, DSCPs SHOULD be chosen that are

       already defined for use with admission-controlled traffic.
       Appendix A gives guidance to implementors on suitable DSCPs.
  • MUST set the PCN codepoint of all PCN-packets to not-marked

(NM).

 4. PCN rate-metering:  This fourth step may be necessary depending on
    the edge behaviour in force.  It is listed for completeness, but
    it is not relevant to this encoding document.

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 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 a packet,
 the PCN-interior-node MUST change NM to ThM.

Briscoe, et al. Standards Track [Page 11] RFC 6660 3-in-1 PCN Encoding July 2012

 If the excess-traffic-meter function indicates a need to mark a
 packet:
 o  the PCN-interior-node MUST change NM to ETM;
 o  the PCN-interior-node MUST change ThM to ETM.
 If both the threshold meter and the excess-traffic meter indicate the
 need to mark a packet, the Excess-traffic-marking rules MUST take
 precedence.

5.2.3. Behaviour of PCN-Interior-Nodes Using One PCN-Marking

 Some PCN edge behaviours require only one PCN-marking within the PCN-
 domain.  The Single Marking edge behaviour [RFC6662] requires PCN-
 interior-nodes to mark packets using the excess-traffic-meter
 function [RFC5670].  It is possible that future schemes may require
 only the threshold-meter function.  Appendix D explains the rationale
 for the behaviours defined in this section.

5.2.3.1. Marking Using Only the Excess-Traffic-Meter Function

 The threshold-traffic-meter function SHOULD be disabled and MUST NOT
 trigger any packet marking.
 The PCN-interior-node SHOULD raise a management alarm if it receives
 a ThM packet, but the frequency of such alarms SHOULD be limited.
 If the excess-traffic-meter function indicates a need to mark the
 packet:
 o  the PCN-interior-node MUST change NM to ETM;
 o  the 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 disabled and MUST NOT
 trigger any packet marking.
 The PCN-interior-node SHOULD raise a management alarm if it receives
 an ETM packet, but the frequency of such alarms SHOULD be limited.
 If the threshold-meter function indicates a need to mark the packet:
 o  the PCN-interior-node MUST change NM to ThM;

Briscoe, et al. Standards Track [Page 12] RFC 6660 3-in-1 PCN Encoding July 2012

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

5.3. PCN-Egress-Node Behaviour

 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 if the PCN-egress-node is 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 expose other ECN codepoints.
 Appendix B gives details of how such schemes might work, but such
 schemes are currently only tentative ideas.
 If the PCN-domain is configured to use only Excess-traffic-marking,
 the PCN-egress-node MUST treat ThM as ETM; if only threshold-marking
 is used, it SHOULD treat ETM as ThM.  However, it SHOULD raise a
 management alarm in either case since this means there is 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 number of factors to be
 taken into consideration.  It also suggests various techniques to
 allow the coexistence of default ECN and alternative ECN semantics.
 The encoding specified in this document uses one of those techniques;
 it defines PCN-compatible Diffserv codepoints as no longer supporting
 the default ECN semantics within a PCN-domain.  As such, this
 document is compatible with BCP 124.
 There is not enough space in one IP header for the 3-in-1 encoding to
 support both ECN marking end-to-end and PCN-marking within a PCN-
 domain.  The non-normative 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.  The normative text in Section 5.1
 requires one of these methods to be configured at the PCN-ingress-
 node and recommends that implementations offer tunnelling as the
 default.
 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 codepoint.

Briscoe, et al. Standards Track [Page 13] RFC 6660 3-in-1 PCN Encoding July 2012

 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 Encoding in RFC 5696

 Section 5.1 of the PCN architecture [RFC5559] gives general guidance
 on fault detection and diagnosis, including management analysis of
 PCN markings arriving at PCN-egress-nodes to detect early signs of
 potential faults.  Because the PCN encoding has gone through an
 obsoleted earlier stage [RFC5696], misconfiguration mistakes may be
 more likely.  Therefore, extra monitoring, such as in the following
 example, may be necessary to detect and diagnose potential problems:
    Informational example: In a controlled-load edge-behaviour
    scenario it could be worth the PCN-egress-node detecting the onset
    of excess-traffic marking without any prior threshold-marking.
    This might indicate that an interior node has been wrongly
    configured to mark only ETM (which would have been correct for the
    single-marking edge behaviour).
 A PCN-node implemented to use the obsoleted encoding in RFC 5696
 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, there is no known deployment of this
 rather unlikely variant of RFC 5696 and no reason to believe that
 such an implementation would ever have been built.  Therefore, it
 seems safe to ignore this issue.

7. Security Considerations

 PCN-marking only carries a meaning within the confines of a PCN-
 domain.  This encoding document is intended to stand independently of
 the 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 the PCN-domain to be entirely under the control
 of a single operator, or a set of operators who trust each other.
 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
 lack of trust.  However, such considerations are beyond the scope of
 this document.

Briscoe, et al. Standards Track [Page 14] RFC 6660 3-in-1 PCN Encoding July 2012

 One potential security concern is the injection of spurious PCN-marks
 into the 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; however, in general, spurious marks will
 lead to admitting fewer flows into the 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.

8. 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.
 In general, the use of this PCN encoding scheme presupposes that any
 tunnel endpoints within the PCN-domain comply with [RFC6040].

9. Acknowledgements

 Many thanks to Philip Eardley for providing extensive feedback,
 criticism and advice.  Thanks also to Teco Boot, Kwok Ho Chan,
 Ruediger Geib, Georgios Karagiannis, James Polk, Tom Taylor, Adrian
 Farrel, and everyone else who has commented on the document.

10. References

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

Briscoe, et al. Standards Track [Page 15] RFC 6660 3-in-1 PCN Encoding July 2012

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

10.2. Informative References

 [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
            "Assured Forwarding PHB Group", RFC 2597, June 1999.
 [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
            Label Switching Architecture", RFC 3031, January 2001.
 [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.

Briscoe, et al. Standards Track [Page 16] RFC 6660 3-in-1 PCN Encoding July 2012

 [RFC6627]  Karagiannis, G., Chan, K., Moncaster, T., Menth, M.,
            Eardley, P., and B. Briscoe, "Overview of Pre-Congestion
            Notification Encoding", RFC 6627, July 2012.
 [RFC6661]  Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
            Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-
            Node Behaviour for the Controlled Load (CL) Mode of
            Operation", RFC 6661, July 2012.
 [RFC6662]  Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T.
            Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-
            Node Behaviour for the Single Marking (SM) Mode of
            Operation", RFC 6662, July 2012.

Briscoe, et al. Standards Track [Page 17] RFC 6660 3-in-1 PCN Encoding July 2012

Appendix A. Choice of Suitable DSCPs

 This appendix is informative not normative.
 A single DSCP has not been defined 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].  It is suggested that
 admission control could be used for the following service classes
 (defined in [RFC4594] unless otherwise stated):
 o  Telephony (EF)
 o  Real-time interactive (CS4)
 o  Broadcast Video (CS3)
 o  Multimedia Conferencing (AF4)
 o  the VOICE-ADMIT codepoint defined in [RFC5865].
 CS5 is excluded from this list since PCN is not expected to be
 applied to signalling traffic.
 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].
 Guidelines for conserving DSCPs by allowing non-admission-controlled-
 traffic to compete with PCN-traffic are given in Appendix B.1 of
 [RFC5670].

Briscoe, et al. Standards Track [Page 18] RFC 6660 3-in-1 PCN Encoding July 2012

 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. Coexistence of ECN and PCN

 This appendix is informative not normative.  It collects together
 material relevant to coexistence of ECN and PCN, including that
 spread throughout the body of this specification.  If this results in
 any conflict or ambiguity, the normative text in the body of the
 specification takes precedence.
 ECN [RFC3168] is an e2e congestion notification mechanism.  As such
 it is possible that some traffic entering the PCN-domain may also be
 ECN-capable.  The PCN encoding described in this document reuses the
 bits of the ECN field in the IP header.  Consequently, this disables
 ECN within the PCN-domain.
 For the purposes of this appendix, we define two forms of traffic
 that might arrive at a PCN-ingress-node.  These are admission-
 controlled traffic (PCN-traffic) and non-admission-controlled traffic
 (non-PCN-traffic).
 Flow signalling identifies admission-controlled traffic, by
 associating a filter spec with the need for admission control (e.g.,
 through RSVP or some equivalent message, such as from a SIP server to
 the ingress or from a logically centralised network control system).
 The PCN-ingress-node re-marks admission-controlled traffic matching
 that filter spec to a PCN-compatible DSCP.  Note that the term "flow"
 need not imply just one microflow, but instead could match an
 aggregate and/or could depend on the incoming DSCP (see Appendix A).
 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.
 Unless specified otherwise, for any of the cases in the list below,
 an IP-in-IP tunnel that complies with [RFC6040] can be used to
 preserve ECN markings across the PCN-domain.  The tunnelling action

Briscoe, et al. Standards Track [Page 19] RFC 6660 3-in-1 PCN Encoding July 2012

 should be applied wholly outside the PCN-domain as illustrated in
 Figure 2.  Then, by the rules of RFC 6040, the tunnel egress
 propagates the ECN field from the inner header, because the PCN-
 egress will have zeroed the outer ECN field.
             .  .  .  .  .  .  PCN-domain  .  .  .  .  .  .
            .   ,---------.                   ,--------.    .
           .   _|  PCN-   |___________________|  PCN-  |_   .
           .  / | ingress |                   | egress | \  .
            .|  `---------'                   `--------'  |.
             | .  .  .  .  .  .  .  .  .  .  .  .  .  .  .|
       ,---------.                                     ,--------.
  _____| Tunnel  |                                     | Tunnel |____
       | Ingress | - - ECN preserved inside tunnel - - | Egress |
       `---------'                                     `--------'
          Figure 2: Separation of Tunnelling and PCN Actions
 There are three cases for how e2e ECN traffic may wish to be treated
 while crossing a PCN-domain:
 a) Traffic that does not require PCN admission control:
    For example, traffic that does not match flow signalling being
    used for admission control.  In this case, the e2e ECN traffic is
    not treated as PCN-traffic.  There are two possible scenarios:
  • Arriving traffic does not carry a PCN-compatible DSCP: no

action required.

  • Arriving traffic carries a DSCP that clashes with a PCN-

compatible DSCP. There are two options:

       1.  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.
       2.  The ingress tunnels the traffic, setting the DSCP in the
           outer header to a local DSCP with the same scheduling PHB
           as the original DSCP.
       3.  The ingress tunnels the traffic, using the original DSCP in
           the outer header but setting not-PCN in the outer header;
           note that this turns off ECN for this traffic within the
           PCN-domain.
       The first or second options are recommended unless the operator
       is short of local DSCPs.

Briscoe, et al. Standards Track [Page 20] RFC 6660 3-in-1 PCN Encoding July 2012

 b) Traffic that requires admission-control:
    In this case, the e2e ECN traffic is treated as PCN-traffic across
    the PCN-domain.  There are two options.
  • The PCN-ingress-node places this traffic 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 drops CE-marked packets and otherwise sets

the ECN-field to NM and sets the DSCP to a PCN-compatible DSCP.

       The PCN-egress zeroes the ECN field of all PCN packets; note
       that this turns off e2e ECN.
    The second option is emphatically not recommended, unless perhaps
    as a last resort if tunnelling is not possible for some
    insurmountable reason.
 c) Traffic that requires PCN admission control where the endpoints
    ask to see PCN marks:
    Note that this scheme is currently only a tentative idea.
    For real-time data generated by an adaptive codec, schemes have
    been suggested where PCN marks may be leaked out of the PCN-domain
    so that end hosts can drop to a lower data-rate, thus deferring
    the need for admission control.  Currently, such schemes require
    further study and the following is for guidance only.
    The PCN-ingress-node needs to tunnel the traffic as in Figure 2,
    taking care to comply with [RFC6040].  In this case, the PCN-
    egress does not zero the ECN field (contrary to the recommendation
    in Section 5.3), so that the [RFC6040] tunnel egress will preserve
    any PCN-marking.  Note that a PCN-interior-node may change the
    ECN-field from '10' to '01' (NM to ThM), which would be
    interpreted by the e2e ECN as a change from ECT(0) into ECT(1).
    This would not be compatible with the (currently experimental) ECN
    nonce [RFC3540].

Briscoe, et al. Standards Track [Page 21] RFC 6660 3-in-1 PCN Encoding July 2012

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 64
 codepoints.  When encapsulating IP traffic in MPLS, it is useful to
 make the DS field information accessible in the MPLS header.
 However, the MPLS shim header has only a 3-bit traffic class (TC)
 field [RFC5462] providing for 8 codepoints.  The operator has the
 freedom to define a site-local mapping of the 64 codepoints of the DS
 field onto the 8 codepoints in the TC field.
 [RFC5129] describes how ECN markings in the IP header can also be
 mapped to codepoints in the MPLS TC field.  Appendix A of [RFC5129]
 gives an informative description of how to support PCN in MPLS by
 extending the way MPLS supports ECN.  [RFC5129] was written while PCN
 specifications were in early draft stages.  The following provides a
 clearer example of a mapping between PCN in IP and in MPLS using the
 PCN terminology and concepts that have since been specified.
 To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n')
 needs codepoints to be provided in the TC field for all the PCN-marks
 used.  That means, when, for instance, only excess-traffic-marking is
 used for PCN purposes, the operator needs to define a site-local
 mapping to two codepoints in the MPLS TC field for IP headers with:
 o  DSCP n and NM
 o  DSCP n and ETM
 If both excess-traffic-marking and threshold-marking are used, the
 operator needs to define a site-local mapping to codepoints in the
 MPLS TC field for IP headers with all three of the 3-in-1 codepoints:
 o  DSCP n and NM
 o  DSCP n and ThM
 o  DSCP n and ETM
 In either case, if the operator wishes to support the same Diffserv
 PHB but without PCN marking, it will also be necessary to define a
 site-local mapping to an MPLS TC codepoint for IP headers marked
 with:
 o  DSCP n and not-PCN

Briscoe, et al. Standards Track [Page 22] RFC 6660 3-in-1 PCN Encoding July 2012

 The above sets of codepoints are required for every PCN-compatible
 DSCP.  Clearly, given so few TC codepoints are available, it may be
 necessary to compromise by merging together some capabilities.
 Guidelines for conserving TC codepoints by allowing non-admission-
 controlled-traffic to compete with PCN-traffic are given in Appendix
 B.1 of [RFC5670].

Appendix D. Rationale for Difference between the Schemes Using One

           PCN-Marking
 Readers may notice a difference between the two behaviours in
 Sections 5.2.3.1 and 5.2.3.2.  With only Excess-traffic-marking
 enabled, an unexpected ThM packet can be re-marked to ETM.  However,
 with only Threshold-marking, an unexpected ETM packet cannot be re-
 marked to ThM.
 This apparent inconsistency is deliberate.  The behaviour with only
 Threshold-marking keeps to the rule of Section 5.2.1 that ETM is more
 severe and must never be changed to ThM even though ETM is not a
 valid marking in this case.  Otherwise, implementations would have to
 allow operators to configure an exception to this rule, which would
 not be safe practice and would require different code in the data
 plane compared to the common behaviour.

Briscoe, et al. Standards Track [Page 23] RFC 6660 3-in-1 PCN Encoding July 2012

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
 University of Cambridge Computer Laboratory
 William Gates Building, J J Thomson Avenue
 Cambridge  CB3 0FD
 UK
 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

Briscoe, et al. Standards Track [Page 24]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6660.txt · Last modified: 2012/07/18 23:27 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki