Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5559

Pre-Congestion Notification (PCN) Architecture

Pages: 54
Informational
Errata
Part 1 of 3 – Pages 1 to 18
None   None   Next

Top   ToC   RFC5559 - Page 1
Network Working Group                                    P. Eardley, Ed.
Request for Comments: 5559                                            BT
Category: Informational                                        June 2009


             Pre-Congestion Notification (PCN) Architecture

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Abstract

This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain.
Top   ToC   RFC5559 - Page 2

Table of Contents

1. Introduction ....................................................3 1.1. Overview of PCN ............................................3 1.2. Example Use Case for PCN ...................................4 1.3. Applicability of PCN .......................................7 1.4. Documents about PCN ........................................8 2. Terminology .....................................................9 3. High-Level Functional Architecture .............................11 3.1. Flow Admission ............................................13 3.2. Flow Termination ..........................................14 3.3. Flow Admission and/or Flow Termination When There Are Only Two PCN Encoding States ...................................15 3.4. Information Transport .....................................16 3.5. PCN-Traffic ...............................................16 3.6. Backwards Compatibility ...................................17 4. Detailed Functional Architecture ...............................18 4.1. PCN-Interior-Node Functions ...............................19 4.2. PCN-Ingress-Node Functions ................................19 4.3. PCN-Egress-Node Functions .................................20 4.4. Admission Control Functions ...............................21 4.5. Flow Termination Functions ................................22 4.6. Addressing ................................................22 4.7. Tunnelling ................................................23 4.8. Fault Handling ............................................25 5. Operations and Management ......................................25 5.1. Fault Operations and Management ...........................25 5.2. Configuration Operations and Management ...................26 5.2.1. System Options .....................................27 5.2.2. Parameters .........................................28 5.3. Accounting Operations and Management ......................30 5.4. Performance and Provisioning Operations and Management ....30 5.5. Security Operations and Management ........................31 6. Applicability of PCN ...........................................32 6.1. Benefits ..................................................32 6.2. Deployment Scenarios ......................................33 6.3. Assumptions and Constraints on Scope ......................35 6.3.1. Assumption 1: Trust and Support of PCN - Controlled Environment .............................36 6.3.2. Assumption 2: Real-Time Applications ...............36 6.3.3. Assumption 3: Many Flows and Additional Load .......37 6.3.4. Assumption 4: Emergency Use Out of Scope ...........37 6.4. Challenges ................................................37 7. Security Considerations ........................................40 8. Conclusions ....................................................41 9. Acknowledgements ...............................................41
Top   ToC   RFC5559 - Page 3
   10. References ....................................................42
      10.1. Normative References .....................................42
      10.2. Informative References ...................................42
   Appendix A.  Possible Future Work Items ...........................48
       A.1.  Probing .................................................50
             A.1.1.  Introduction ....................................50
             A.1.2.  Probing Functions ...............................50
             A.1.3.  Discussion of Rationale for Probing, Its
                     Downsides and Open Issues .......................51

1. Introduction

1.1. Overview of PCN

The objective of Pre-Congestion Notification (PCN) 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 (in abnormal circumstances) flow termination, to decide whether to terminate some of the existing flows. 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 congestion occurs (hence, "Pre-Congestion Notification"). The level of marking allows boundary nodes to make decisions about whether to admit or terminate. Within a PCN-domain, PCN-traffic is forwarded in a prioritised Diffserv traffic class. Every link in the PCN-domain is configured with two rates (PCN-threshold-rate and PCN-excess-rate). If the overall rate of PCN-traffic on a link exceeds a configured rate, then a PCN-interior-node marks PCN-packets appropriately. The PCN-egress- nodes use this information to make admission control and flow termination decisions. Flow admission control determines whether a new flow can be admitted without any impact, in normal circumstances, on the QoS of existing PCN-flows. However, in abnormal circumstances (for instance, a disaster affecting multiple nodes and causing traffic re-routes), the QoS on existing PCN-flows may degrade even though care was exercised when admitting those flows. The flow termination mechanism removes sufficient traffic in order to protect the QoS of the remaining PCN-flows. All PCN-boundary-nodes and PCN- interior-nodes are PCN-enabled and are trusted for correct PCN operation. PCN-ingress-nodes police arriving packets to check that they are part of an admitted PCN-flow that keeps within its agreed flowspec, and hence they maintain per-flow state. PCN-interior-nodes meter all PCN-traffic, and hence do not need to maintain any per-flow
Top   ToC   RFC5559 - Page 4
   state.  Decisions about flow admission and termination are made for a
   particular pair of PCN-boundary-nodes, and hence PCN-egress-nodes
   must be able to identify which PCN-ingress-node sent each PCN-packet.

1.2. Example Use Case for PCN

This section outlines an end-to-end QoS scenario that uses the PCN mechanisms within one domain. The parts outside the PCN-domain are out of scope for PCN, but are included to help clarify how PCN could be used. Note that this section is only an example -- in particular, there are other possibilities (see Section 3) for how the PCN- boundary-nodes perform admission control and flow termination. As a fundamental building block, each link of the PCN-domain operates the following. Please refer to [Eardley09] and Figure 1. o A threshold meter and marker, which marks all PCN-packets if the rate of PCN-traffic is greater than a first configured rate, the PCN-threshold-rate. The admission control mechanism limits the PCN-traffic on each link to *roughly* its PCN-threshold-rate. o An excess-traffic meter and marker, which marks a proportion of PCN-packets such that the amount marked equals the traffic rate in excess of a second configured rate, the PCN-excess-rate. The flow termination mechanism limits the PCN-traffic on each link to *roughly* its PCN-excess-rate. Overall, the aim is to give an "early warning" of potential congestion before there is any significant build-up of PCN-packets in the queue on the link; we term this "Pre-Congestion Notification" by analogy with ECN (Explicit Congestion Notification, [RFC3168]). Note that the link only meters the bulk PCN-traffic (and not per flow).
Top   ToC   RFC5559 - Page 5
                          ==   Metering &    ==
                          ==Marking behaviour==       ==PCN mechanisms==
                       ^
           Rate of     ^
      PCN-traffic on   |
     bottleneck link   |
                       |
                       |       Some pkts                  Terminate some
                       |  excess-traffic-marked           admitted flows
                       |           &                            &
                       |     Rest of pkts                Block new flows
                       |   threshold-marked
                       |
     PCN-excess-rate  -|------------------------------------------------
(=PCN-supportable-rate)|
                       |       All pkts                  Block new flows
                       |   threshold-marked
                       |
   PCN-threshold-rate -|------------------------------------------------
 (=PCN-admissible-rate)|
                       |        No pkts                  Admit new flows
                       |      PCN-marked
                       |

   Figure 1: Example of how the PCN admission control and flow
   termination mechanisms operate as the rate of PCN-traffic increases.

   The two forms of PCN-marking are indicated by setting the ECN and
   DSCP (Differentiated Services Codepoint [RFC2474]) fields to known
   values, which are configured for the domain.  Thus, the PCN-egress-
   nodes can monitor the PCN-markings in order to measure the severity
   of pre-congestion.  In addition, the PCN-ingress-nodes need to set
   the ECN and DSCP fields to that configured for an unmarked PCN-
   packet, and the PCN-egress-nodes need to revert to values appropriate
   outside the PCN-domain.

   For admission control, we assume end-to-end RSVP (Resource
   Reservation Protocol) [RFC2205]) signalling in this example.  The
   PCN-domain is a single RSVP hop.  The PCN-domain operates Diffserv,
   and we assume that PCN-traffic is scheduled with the expedited
   forwarding (EF) per-hop behaviour [RFC3246].  Hence, the overall
   solution is in line with the "IntServ over Diffserv" framework
   defined in [RFC2998], as shown in Figure 2.
Top   ToC   RFC5559 - Page 6
   ___    ___    _______________________________________    ____    ___
  |   |  |   |  | PCN-             PCN-            PCN- |  |    |  |   |
  |   |  |   |  |ingress         interior         egress|  |    |  |   |
  |   |  |   |  | -node           -nodes          -node |  |    |  |   |
  |   |  |   |  |-------+  +-------+  +-------+  +------|  |    |  |   |
  |   |  |   |  |       |  | PCN   |  | PCN   |  |      |  |    |  |   |
  |   |..|   |..|Ingress|..|meter &|..|meter &|..|Egress|..|    |..|   |
  |   |..|   |..|Policer|..|marker |..|marker |..|Meter |..|    |..|   |
  |   |  |   |  |-------+  +-------+  +-------+  +------|  |    |  |   |
  |   |  |   |  |  \                                 /  |  |    |  |   |
  |   |  |   |  |   \                               /   |  |    |  |   |
  |   |  |   |  |    \  PCN-feedback-information   /    |  |    |  |   |
  |   |  |   |  |     \  (for admission control)  /     |  |    |  |   |
  |   |  |   |  |      --<-----<----<----<-----<--      |  |    |  |   |
  |   |  |   |  |       PCN-feedback-information        |  |    |  |   |
  |   |  |   |  |        (for flow termination)         |  |    |  |   |
  |___|  |___|  |_______________________________________|  |____|  |___|

  Sx     Access               PCN-domain                   Access    Rx
  End    Network                                          Network   End
  Host                                                              Host
                  <---- signalling across PCN-domain--->
                (for admission control & flow termination)

  <-------------------end-to-end QoS signalling protocol--------------->

   Figure 2: Example of possible overall QoS architecture.

   A source wanting to start a new QoS flow sends an RSVP PATH message.
   Normal hop-by-hop IntServ [RFC1633] is used outside the PCN-domain
   (we assume successfully).  The PATH message travels across the PCN-
   domain; the PCN-egress-node reads the PHOP (previous RSVP hop) object
   to discover the specific PCN-ingress-node for this flow.  The RESV
   message travels back from the receiver, and triggers the PCN-egress-
   node to check what fraction of the PCN-traffic from the relevant PCN-
   ingress-node is currently being threshold-marked.  It adds an object
   with this information onto the RESV message, and hence the PCN-
   ingress-node learns about the level of pre-congestion on the path.
   If this level is below some threshold, then the PCN-ingress-node
   admits the new flow into the PCN-domain.  The RSVP message triggers
   the PCN-ingress-node to install two normal IntServ items: five-tuple
   information, so that it can subsequently identify data packets that
   are part of a previously admitted PCN-flow, and a traffic profile, so
   that it can police the flow to within its reservation.  Similarly,
   the RSVP message triggers the PCN-egress-node to install five-tuple
   and PHOP information so that it can identify packets as part of a
   flow from a specific PCN-ingress-node.
Top   ToC   RFC5559 - Page 7
   The flow termination mechanism may happen when some abnormal
   circumstance causes a link to become so pre-congested that it excess-
   traffic-marks (and perhaps also drops) PCN-packets.  In this example,
   when a PCN-egress-node observes such a packet, it then, with some
   probability, terminates this PCN-flow; the probability is configured
   low enough to avoid over termination and high enough to ensure rapid
   termination of enough flows.  It also informs the relevant PCN-
   ingress-node so that it can block any further traffic on the
   terminated flow.

1.3. Applicability of PCN

Compared with alternative QoS mechanisms, PCN has certain advantages and disadvantages that will make it appropriate in particular scenarios. For example, compared with hop-by-hop IntServ [RFC1633], PCN only requires per-flow state at the PCN-ingress-nodes. Compared with the Diffserv architecture [RFC2475], an operator needs to be less accurate and/or conservative in its prediction of the traffic matrix. The Diffserv architecture's traffic-conditioning agreements are static and coarse; they are defined at subscription time and are used (for instance) to limit the total traffic at each ingress of the domain, regardless of the egress for the traffic. On the other hand, PCN firstly uses admission control based on measurements of the current conditions between the specific pair of PCN-boundary-nodes, and secondly, in case of a disaster, PCN protects the QoS of most flows by terminating a few selected ones. PCN's admission control is a measurement-based mechanism. Hence, it assumes that the present is a reasonable prediction of the future: the network conditions are measured at the time of a new flow request, but the actual network performance must be acceptable during the call some time later. Hence, PCN is unsuitable in several circumstances: o If the source adapts its bit rate dependent on the level of pre- congestion, because then the aggregate traffic might become unstable. The assumption in this document is that PCN-packets come from real-time applications generating inelastic traffic, such as the Controlled Load Service [RFC2211]. o If a potential bottleneck link has capacity for only a few flows, because then a new flow can move a link directly from no pre- congestion to being so overloaded that it has to drop packets. The assumption in this document is that this isn't a problem. o If there is the danger of a "flash crowd", in which many admission requests arrive within the reaction time of PCN's admission mechanism, because then they all might get admitted and so
Top   ToC   RFC5559 - Page 8
      overload the network.  The assumption in this document is that, if
      it is necessary, then flash crowds are limited in some fashion
      beyond the scope of this document, for instance by rate-limiting
      QoS requests.

   The applicability of PCN is discussed further in Section 6.

1.4. Documents about PCN

The purpose of this document is to describe a general architecture for flow admission and termination based on (pre-)congestion information in order to protect the quality of service of flows within a Diffserv domain. This document describes the PCN architecture at a high level (Section 3) and in more detail (Section 4). It also defines some terminology, and provides considerations about operations, management, and security. Section 6 considers the applicability of PCN in more detail, covering its benefits, deployment scenarios, assumptions, and potential challenges. The Appendix covers some potential future work items. Aspects of PCN are also documented elsewhere: o Metering and marking: [Eardley09] standardises threshold metering and marking and excess-traffic metering and marking. A PCN-packet may be marked, depending on the metering results. o Encoding: the "baseline" encoding is described in [Moncaster09-1], which standardises two PCN encoding states (PCN-marked and not PCN-marked), whilst (experimental) extensions to the baseline encoding can provide three encoding states (threshold-marked, excess-traffic-marked, or not PCN-marked), for instance, see [Moncaster09-2]. (There may be further encoding states as suggested in [Westberg08].) Section 3.6 considers the backwards compatibility of PCN encoding with ECN. o PCN-boundary-node behaviour: how the PCN-boundary-nodes convert the PCN-markings into decisions about flow admission and flow termination, as described in Informational documents such as [Taylor09] and [Charny07-2]. The concept is that the standardised metering and marking by PCN-nodes allows several possible PCN- boundary-node behaviours. A number of possibilities are outlined in this document; detailed descriptions and comparisons are in [Charny07-1] and [Menth09-2]. o Signalling between PCN-boundary-nodes: signalling is needed to transport PCN-feedback-information between the PCN-boundary-nodes (in the example above, this is the fraction of traffic, between the pair of PCN-boundary-nodes, that is PCN-marked). The exact
Top   ToC   RFC5559 - Page 9
      details vary for different PCN-boundary-node behaviours, and so
      should be described in those documents.  It may require an
      extension to the signalling protocol -- standardisation is out of
      scope of the PCN WG.

   o  The interface by which the PCN-boundary-nodes learn identification
      information about the admitted flows: the exact requirements vary
      for different PCN-boundary-node behaviours and for different
      signalling protocols, and so should be described in those
      documents.  They will be similar to those described in the example
      above -- a PCN-ingress-node needs to be able to identify that a
      packet is part of a previously admitted flow (typically from its
      five-tuple) and each PCN-boundary-node needs to be able to
      identify the other PCN-boundary-node for the flow.

2. Terminology

o PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled nodes that perform Diffserv scheduling [RFC2474]; the complete set of PCN-nodes that in principle can, through PCN-marking packets, influence decisions about flow admission and termination for the PCN-domain; includes the PCN-egress-nodes, which measure these PCN-marks, and the PCN-ingress-nodes. o PCN-boundary-node: a PCN-node that connects one PCN-domain to a node either in another PCN-domain or in a non-PCN-domain. o PCN-interior-node: a node in a PCN-domain that is not a PCN- boundary-node. o PCN-node: a PCN-boundary-node or a PCN-interior-node. o PCN-egress-node: a PCN-boundary-node in its role in handling traffic as it leaves a PCN-domain. o PCN-ingress-node: a PCN-boundary-node in its role in handling traffic as it enters a PCN-domain. o PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic of different Diffserv behaviour aggregates (BAs) [RFC2474]. The PCN-BA uses the PCN mechanisms to carry PCN-traffic, and the corresponding packets are PCN-packets. The same network will carry traffic of other Diffserv BAs. The PCN-BA is distinguished by a combination of the Diffserv codepoint (DSCP) and ECN fields.
Top   ToC   RFC5559 - Page 10
   o  PCN-flow: the unit of PCN-traffic that the PCN-boundary-node
      admits (or terminates); the unit could be a single microflow (as
      defined in [RFC2474]) or some identifiable collection of
      microflows.

   o  Pre-congestion: a condition of a link within a PCN-domain such
      that the PCN-node performs PCN-marking, in order to provide an
      "early warning" of potential congestion before there is any
      significant build-up of PCN-packets in the real queue.  (Hence, by
      analogy with ECN, we call our mechanism Pre-Congestion
      Notification.)

   o  PCN-marking: the process of setting the header in a PCN-packet
      based on defined rules, in reaction to pre-congestion; either
      threshold-marking or excess-traffic-marking.  Such a packet is
      then called PCN-marked.

   o  Threshold-metering: a metering behaviour that, if the PCN-traffic
      exceeds the PCN-threshold-rate, indicates that all PCN-traffic is
      to be threshold-marked.

   o  PCN-threshold-rate: the reference rate of a threshold-meter, which
      is configured for each link in the PCN-domain and which is lower
      than the PCN-excess-rate.

   o  Threshold-marking: the setting of the header in a PCN-packet to a
      specific encoding, based on indications from the threshold-meter.
      Such a packet is then called threshold-marked.

   o  Excess-traffic-metering: a metering behaviour that, if the PCN-
      traffic exceeds the PCN-excess-rate, indicates that the amount of
      PCN-traffic to be excess-traffic-marked is equal to the amount in
      excess of the PCN-excess-rate.

   o  PCN-excess-rate: the reference rate of an excess-traffic-meter,
      which is a configured for each link in the PCN-domain and which is
      higher than the PCN-threshold-rate.

   o  Excess-traffic-marking: the setting of the header in a PCN-packet
      to a specific encoding, based on indications from the excess-
      traffic-meter.  Such a packet is then called excess-traffic-
      marked.

   o  PCN-colouring: the process of setting the header in a PCN-packet
      by a PCN-boundary-node; performed by a PCN-ingress-node so that
      PCN-nodes can easily identify PCN-packets; performed by a PCN-
      egress-node so that the header is appropriate for nodes beyond the
      PCN-domain.
Top   ToC   RFC5559 - Page 11
   o  Ingress-egress-aggregate: The collection of PCN-packets from all
      PCN-flows that travel in one direction between a specific pair of
      PCN-boundary-nodes.

   o  PCN-feedback-information: information signalled by a PCN-egress-
      node to a PCN-ingress-node (or a central control node), which is
      needed for the flow admission and flow termination mechanisms.

   o  PCN-admissible-rate: the rate of PCN-traffic on a link up to which
      PCN admission control should accept new PCN-flows.

   o  PCN-supportable-rate: the rate of PCN-traffic on a link down to
      which PCN flow termination should, if necessary, terminate already
      admitted PCN-flows.

3. High-Level Functional Architecture

The high-level approach is to split functionality between: o PCN-interior-nodes "inside" the PCN-domain, which monitor their own state of pre-congestion and mark PCN-packets as appropriate. They are not flow-aware, nor are they aware of ingress-egress- aggregates. The functionality is also done by PCN-ingress-nodes for their outgoing interfaces (ie, those "inside" the PCN-domain). o PCN-boundary-nodes at the edge of the PCN-domain, which control admission of new PCN-flows and termination of existing PCN-flows, based on information from PCN-interior-nodes. This information is in the form of the PCN-marked data packets (which are intercepted by the PCN-egress-nodes) and is not in signalling messages. Generally, PCN-ingress-nodes are flow-aware. The aim of this split is to keep the bulk of the network simple, scalable, and robust, whilst confining policy, application-level, and security interactions to the edge of the PCN-domain. For example, the lack of flow awareness means that the PCN-interior-nodes don't care about the flow information associated with PCN-packets, nor do the PCN-boundary-nodes care about which PCN-interior-nodes its ingress-egress-aggregates traverse. In order to generate information about the current state of the PCN- domain, each PCN-node PCN-marks packets if it is "pre-congested". Exactly when a PCN-node decides if it is "pre-congested" (the algorithm) and exactly how packets are "PCN-marked" (the encoding) will be defined in separate Standards Track documents, but at a high level it is as follows:
Top   ToC   RFC5559 - Page 12
   o  the algorithms: a PCN-node meters the amount of PCN-traffic on
      each one of its outgoing (or incoming) links.  The measurement is
      made as an aggregate of all PCN-packets, not per flow.  There are
      two algorithms: one for threshold-metering and one for excess-
      traffic-metering.  The meters trigger PCN-marking as necessary.

   o  the encoding(s): a PCN-node PCN-marks a PCN-packet by modifying a
      combination of the DSCP and ECN fields.  In the "baseline"
      encoding [Moncaster09-1], the ECN field is set to 11 and the DSCP
      is not altered.  Extension encodings may be defined that, at most,
      use a second DSCP (eg, as in [Moncaster09-2]) and/or set the ECN
      field to values other than 11 (eg, as in [Menth08-2]).

   In a PCN-domain, the operator may have two or three encoding states
   available.  The baseline encoding provides two encoding states (not
   PCN-marked and PCN-marked), whilst extended encodings can provide
   three encoding states (not PCN-marked, threshold-marked, and excess-
   traffic-marked).

   An operator may choose to deploy either admission control or flow
   termination or both.  Although designed to work together, they are
   independent mechanisms, and the use of one does not require or
   prevent the use of the other.  Three encoding states naturally allows
   both flow admission and flow termination.  If there are only two
   encoding states, then there are several options -- see Section 3.3.

   The PCN-boundary-nodes monitor the PCN-marked packets in order to
   extract information about the current state of the PCN-domain.  Based
   on this monitoring, a distributed decision is made about whether to
   admit a prospective new flow or terminate existing flow(s).  Sections
   4.4 and 4.5 mention various possibilities for how the functionality
   could be distributed.

   PCN-metering and PCN-marking need to be configured on all
   (potentially pre-congested) links in the PCN-domain to ensure that
   the PCN mechanisms protect all links.  The actual functionality can
   be configured on the outgoing or incoming interfaces of PCN-nodes --
   or one algorithm could be configured on the outgoing interface and
   the other on the incoming interface.  The important point is that a
   consistent choice is made across the PCN-domain to ensure that the
   PCN mechanisms protect all links.  See [Eardley09] for further
   discussion.

   The objective of threshold-marking, as triggered by the threshold-
   metering algorithm, is to threshold-mark all PCN-packets whenever the
   bit rate of PCN-packets is greater than some configured rate, the
   PCN-threshold-rate.  The objective of excess-traffic-metering, as
   triggered by the excess-traffic-marking algorithm, is to excess-
Top   ToC   RFC5559 - Page 13
   traffic-mark PCN-packets at a rate equal to the difference between
   the bit rate of PCN-packets and some configured rate, the PCN-excess-
   rate.  Note that this description reflects the overall intent of the
   algorithms rather than their instantaneous behaviour, since the rate
   measured at a particular moment depends on the detailed algorithm,
   its implementation, and the traffic's variance as well as its rate
   (eg, marking may well continue after a recent overload, even after
   the instantaneous rate has dropped).  The algorithms are specified in
   [Eardley09].

   Admission and termination approaches are detailed and compared in
   [Charny07-1] and [Menth09-2].  The discussion below is just a brief
   summary.  Sections 3.1 and 3.2 assume there are three encoding states
   available, whilst Section 3.3 assumes there are two encoding states
   available.

   From the perspective of the outside world, a PCN-domain essentially
   looks like a Diffserv domain, but without the Diffserv architecture's
   traffic-conditioning agreements.  PCN-traffic is either transported
   across it transparently or policed at the PCN-ingress-node (ie,
   dropped or carried at a lower QoS).  One difference is that PCN-
   traffic has better QoS guarantees than normal Diffserv traffic
   because the PCN mechanisms better protect the QoS of admitted flows.
   Another difference may occur in the rare circumstance when there is a
   failure: on the one hand, some PCN-flows may get terminated but, on
   the other hand, other flows will get their QoS restored.  Non-PCN-
   traffic is treated transparently, ie, the PCN-domain is a normal
   Diffserv domain.

3.1. Flow Admission

The objective of PCN's flow admission control mechanism is to limit the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- admissible-rate by admitting or blocking prospective new flows, in order to protect the QoS of existing PCN-flows. With three encoding states available, the PCN-threshold-rate is configured by the operator as equal to the PCN-admissible-rate on each link. It is set lower than the traffic rate at which the link becomes congested and the node drops packets. Exactly how the admission control decision is made will be defined separately in Informational documents. This document describes two approaches (others might be possible): o The PCN-egress-node measures (possibly as a moving average) the fraction of the PCN-traffic that is threshold-marked. The fraction is measured for a specific ingress-egress-aggregate. If the fraction is below a threshold value, then the new flow is
Top   ToC   RFC5559 - Page 14
      admitted; if the fraction is above the threshold value, then it is
      blocked.  The fraction could be measured as an EWMA (exponentially
      weighted moving average), which has sometimes been called the
      "congestion level estimate".

   o  The PCN-egress-node monitors PCN-traffic and if it receives one
      (or several) threshold-marked packets, then the new flow is
      blocked; otherwise, it is admitted.  One possibility may be to
      react to the marking state of an initial flow-setup packet (eg,
      RSVP PATH).  Another is that after one (or several) threshold-
      marks, all flows are blocked until after a specific period of no
      congestion.

   Note that the admission control decision is made for a particular
   pair of PCN-boundary-nodes.  So it is quite possible for a new flow
   to be admitted between one pair of PCN-boundary-nodes, whilst at the
   same time another admission request is blocked between a different
   pair of PCN-boundary-nodes.

3.2. Flow Termination

The objective of PCN's flow termination mechanism is to limit the PCN-traffic on each link to *roughly* its PCN-supportable-rate, by terminating some existing PCN-flows, in order to protect the QoS of the remaining PCN-flows. With three encoding states available, the PCN-excess-rate is configured by the operator as equal to the PCN- supportable-rate on each link. It may be set lower than the traffic rate at which the link becomes congested and at which the node drops packets. Exactly how the flow termination decision is made will be defined separately in Informational documents. This document describes several approaches (others might be possible): o In one approach, the PCN-egress-node measures the rate of PCN- traffic that is not excess-traffic-marked, which is the amount of PCN-traffic that can actually be supported, and communicates this to the PCN-ingress-node. Also, the PCN-ingress-node measures the rate of PCN-traffic that is destined for this specific PCN-egress- node. The difference represents the excess amount that should be terminated. o Another approach instead measures the rate of excess-traffic- marked traffic and terminates this amount of traffic. This terminates less traffic than the previous approach, if some nodes are dropping PCN-traffic.
Top   ToC   RFC5559 - Page 15
   o  Another approach monitors PCN-packets and terminates some of the
      PCN-flows that have an excess-traffic-marked packet.  (If all such
      flows were terminated, far too much traffic would be terminated,
      so a random selection needs to be made from those with an excess-
      traffic-marked packet [Menth08-1].)

   Since flow termination is designed for "abnormal" circumstances, it
   is quite likely that some PCN-nodes are congested and, hence, that
   packets are being dropped and/or significantly queued.  The flow
   termination mechanism must accommodate this.

   Note also that the termination control decision is made for a
   particular pair of PCN-boundary-nodes.  So it is quite possible for
   PCN-flows to be terminated between one pair of PCN-boundary-nodes,
   whilst at the same time none are terminated between a different pair
   of PCN-boundary-nodes.

3.3. Flow Admission and/or Flow Termination When There Are Only Two PCN Encoding States

If a PCN-domain has only two encoding states available (PCN-marked and not PCN-marked), ie, it is using the baseline encoding [Moncaster09-1], then an operator has three options (others might be possible): o admission control only: PCN-marking means threshold-marking, ie, only the threshold-metering algorithm triggers PCN-marking. Only PCN admission control is available. o flow termination only: PCN-marking means excess-traffic-marking, ie, only the excess-traffic-metering algorithm triggers PCN- marking. Only PCN termination control is available. o both admission control and flow termination: only the excess- traffic-metering algorithm triggers PCN-marking; however, the configured rate (PCN-excess-rate) is set equal to the PCN- admissible-rate, as shown in Figure 3. [Charny07-2] describes how both admission control and flow termination can be triggered in this case and also gives some pros and cons of this approach. The main downside is that admission control is less accurate.
Top   ToC   RFC5559 - Page 16
                          ==   Metering &    ==
                          ==Marking behaviour==       ==PCN mechanisms==
                       ^
           Rate of     ^
      PCN-traffic on   |
     bottleneck link   |                                  Terminate some
                       |                                  admitted flows
                       |                                         &
                       |                                 Block new flows
                       |
                       |       Some pkts
   U*PCN-excess-rate  -|  excess-traffic-marked        -----------------
(=PCN-supportable-rate)|
                       |                                 Block new flows
                       |
                       |
     PCN-excess-rate  -|------------------------------------------------
 (=PCN-admissible-rate)|
                       |         No pkts                 Admit new flows
                       |       PCN-marked
                       |

   Figure 3: Schematic of how the PCN admission control and flow
   termination mechanisms operate as the rate of PCN-traffic increases,
   for a PCN-domain with two encoding states and using the approach of
   [Charny07-2].  Note: U is a global parameter for all links in the
   PCN-domain.

3.4. Information Transport

The transport of pre-congestion information from a PCN-node to a PCN- egress-node is through PCN-markings in data packet headers, ie, "in- band"; no signalling protocol messaging is needed. Signalling is needed to transport PCN-feedback-information -- for example, to convey the fraction of PCN-marked traffic from a PCN-egress-node to the relevant PCN-ingress-node. Exactly what information needs to be transported will be described in future documents about possible boundary mechanisms. The signalling could be done by an extension of RSVP or NSIS (Next Steps in Signalling), for instance; [Lefaucheur06] describes the extensions needed for RSVP.

3.5. PCN-Traffic

The following are some high-level points about how PCN works: o There needs to be a way for a PCN-node to distinguish PCN-traffic from other traffic. This is through a combination of the DSCP field and/or ECN field.
Top   ToC   RFC5559 - Page 17
   o  It is not advised to have competing-non-PCN-traffic but, if there
      is such traffic, there needs to be a mechanism to limit it.
      "Competing-non-PCN-traffic" means traffic that shares a link with
      PCN-traffic and competes for its forwarding bandwidth.  Hence,
      more competing-non-PCN-traffic results in poorer QoS for PCN.
      Further, the unpredictable amount of competing-non-PCN-traffic
      makes the PCN mechanisms less accurate and so reduces PCN's
      ability to protect the QoS of admitted PCN-flows.

   o  Two examples of such competing-non-PCN-traffic are:

      1.  traffic that is priority scheduled over PCN (perhaps a
          particular application or an operator's control messages);

      2.  traffic that is scheduled at the same priority as PCN (for
          example, if the Voice-Admit codepoint is used for PCN-traffic
          [Moncaster09-1] and there is non-PCN, voice-admit traffic in
          the PCN-domain).

   o  If there is such competing-non-PCN-traffic, then PCN's mechanisms
      should take account of it, in order to improve the accuracy of the
      decision about whether to admit (or terminate) a PCN-flow.  For
      example, one mechanism is that such competing-non-PCN-traffic
      contributes to the PCN-meters (ie, is metered by the threshold-
      marking and excess-traffic-marking algorithms).

   o  There will be other non-PCN-traffic that doesn't compete for the
      same forwarding bandwidth as PCN-traffic, because it is forwarded
      at lower priority.  Hence, it shouldn't contribute to the PCN-
      meters.  Examples are best-effort and assured-forwarding traffic.
      However, a PCN-node should dedicate some capacity to lower-
      priority traffic so that it isn't starved.

   o  This document assumes that the PCN mechanisms are applied to a
      single behaviour aggregate in the PCN-domain.  However, it would
      also be possible to apply them independently to more than one
      behaviour aggregate, which are distinguished by DSCP.

3.6. Backwards Compatibility

PCN specifies semantics for the ECN field that differ from the default semantics of [RFC3168]. A particular PCN encoding scheme needs to describe how it meets the guidelines of BCP 124 [RFC4774] for specifying alternative semantics for the ECN field. In summary, the approach is to: o use a DSCP to allow PCN-nodes to distinguish PCN-traffic that uses the alternative ECN semantics;
Top   ToC   RFC5559 - Page 18
   o  define these semantics for use within a controlled region, the
      PCN-domain;

   o  take appropriate action if ECN-capable, non-PCN-traffic arrives at
      a PCN-ingress-node with the DSCP used by PCN.

   For the baseline encoding [Moncaster09-1], the "appropriate action"
   is to block ECN-capable traffic that uses the same DSCP as PCN from
   entering the PCN-domain directly.  "Blocking" means it is dropped or
   downgraded to a lower-priority behaviour aggregate, or alternatively
   such traffic may be tunnelled through the PCN-domain.  The reason
   that "appropriate action" is needed is that the PCN-egress-node
   clears the ECN field to 00.

   Extended encoding schemes may need to take different "appropriate
   action".



(page 18 continued on part 2)

Next Section