Pre-Congestion Notification (PCN) Architecture
draft-ietf-pcn-architecture-11

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on October 9, 2009.

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.

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.

Status

Table of Contents

1.  Introduction
    1.1.  Overview of PCN
    1.2.  Example use case for PCN
    1.3.  Applicability of PCN
    1.4.  Documents about PCN
2.  Terminology
3.  High-level functional architecture
    3.1.  Flow admission
    3.2.  Flow termination
    3.3.  Flow admission and/or flow termination when there are only two PCN encoding states
    3.4.  Information transport
    3.5.  PCN-traffic
    3.6.  Backwards compatibility
4.  Detailed Functional architecture
    4.1.  PCN-interior-node functions
    4.2.  PCN-ingress-node functions
    4.3.  PCN-egress-node functions
    4.4.  Admission control functions
    4.5.  Flow termination functions
    4.6.  Addressing
    4.7.  Tunnelling
    4.8.  Fault handling
5.  Operations and Management
    5.1.  Configuration Operations and Management
        5.1.1.  System options
        5.1.2.  Parameters
    5.2.  Performance & Provisioning Operations and Management
    5.3.  Accounting Operations and Management
    5.4.  Fault Operations and Management
    5.5.  Security Operations and Management
6.  Applicability of PCN
    6.1.  Benefits
    6.2.  Deployment scenarios
    6.3.  Assumptions and constraints on scope
        6.3.1.  Assumption 1: Trust and support of PCN - controlled environment
        6.3.2.  Assumption 2: Real-time applications
        6.3.3.  Assumption 3: Many flows and additional load
        6.3.4.  Assumption 4: Emergency use out of scope
    6.4.  Challenges
7.  IANA Considerations
8.  Security considerations
9.  Conclusions
10.  Acknowledgements
11.  Comments Solicited (to be removed by RFC Editor)
12.  Changes (to be removed by RFC Editor)
    12.1.  Changes from -10 to -11
    12.2.  Changes from -09 to -10
    12.3.  Changes from -08 to -09
    12.4.  Changes from -07 to -08
    12.5.  Changes from -06 to -07
    12.6.  Changes from -05 to -06
    12.7.  Changes from -04 to -05
    12.8.  Changes from -03 to -04
    12.9.  Changes from -02 to -03
    12.10.  Changes from -01 to -02
    12.11.  Changes from -00 to -01
13.  References
    13.1.  Normative References
    13.2.  Informative References
Appendix A.  Possible future work items
    A.1.  Probing
        A.1.1.  Introduction
        A.1.2.  Probing functions
        A.1.3.  Discussion of rationale for probing, its downsides and open issues
§  Author's Address

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, then 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 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 the section is only an example – in particular there are other possibilities (see later) for how the PCN-boundary-nodes perform admission control and flow termination.

As a fundamental building block, each link of the PCN-domain operates a [PCN08‑2] (, “Metering and marking behaviour of PCN-nodes (work in progress),” Oct 2008.) (Figure 1):

• Threshold meter and marker, which marks all PCN-packets if the PCN traffic rate 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.
• 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] (Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.)). Note that the link only meters the bulk PCN-traffic (and not per flow).

                          ==   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 of the ECN and DSCP (Differentiated Services Codepoint [RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.)) 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 signalling (Resource Reservation Protocol) [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.)) 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] (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),” March 2002.). Hence the overall solution is in line with the "IntServ over Diffserv" framework defined in [RFC2998] (Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, “A Framework for Integrated Services Operation over Diffserv Networks,” November 2000.), as shown in Figure 2.

 ___    ___    _______________________________________    ____    ___
|   |  |   |  | 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] (Braden, B., Clark, D., and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” June 1994.) is used outside the PCN-domain (we assume successfully). The PATH message travels across the PCN-domain; the PCN-egress-node reads the PHOP 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 contract. 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.

The flow termination mechanism may happen when some abnormal circumstances 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 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] (Braden, B., Clark, D., and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” June 1994.), PCN only requires per flow state at the PCN-ingress-nodes. Compared with the Diffserv architecture [RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.), 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 they 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:

• 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] (Wroclawski, J., “Specification of the Controlled-Load Network Element Service,” September 1997.).
• 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.
• 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 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 considerations about operations and 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:

• Metering and marking: [PCN08‑2] (, “Metering and marking behaviour of PCN-nodes (work in progress),” Oct 2008.) standardises threshold metering and marking, and excess traffic metering and marking. A PCN-packet may be marked, depending on the metering results.
• Encoding: the "baseline" encoding is described in [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information (work in progress),” Oct 2008.), 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, not PCN-marked, or perhaps further encoding states as suggested in [Westberg08] (, “LC-PCN: The Load Control PCN Solution (work in progress),” November 2008.)). Section 3.6 considers backwards compatability of PCN encoding with ECN.
• 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. 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] (, “Comparison of Proposed PCN Approaches (work in progress),” November 2007.) and [Menth08‑3] (, “PCN-Based Admission Control and Flow Termination,” 2008.).
• 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 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.
• 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

• PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled nodes that perform Diffserv scheduling [RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.); 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; the PCN-domain includes the PCN-egress-nodes, which measure these PCN-marks, and the PCN-ingress-nodes.
• 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.
• PCN-interior-node: a node in a PCN-domain that is not a PCN-boundary-node.
• PCN-node: a PCN-boundary-node or a PCN-interior-node
• PCN-egress-node: a PCN-boundary-node in its role in handling traffic as it leaves a PCN-domain.
• PCN-ingress-node: a PCN-boundary-node in its role in handling traffic as it enters a PCN-domain.
• PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic of different Diffserv behaviour aggregates (BAs) [RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.). 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.
• 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] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.)) or some identifiable collection of microflows.
• 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.)
• 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.
• PCN-threshold-rate: a reference rate configured for each link in the PCN-domain, which is lower than the PCN-excess-rate. It is used by a metering behaviour that determines whether a packet should be PCN-marked with a first encoding, "threshold-marked".
• 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.
• Threshold-marking: the setting of the header in a PCN-packet to a specific encoding, based on indications from the threshold-meter.
• PCN-excess-rate: a reference rate configured for each link in the PCN-domain, which is higher than the PCN-threshold-rate. It is used by a metering behaviour that determines whether a packet should be PCN-marked with a second encoding, "excess-traffic-marked".
• 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 PCN-marked is equal to the amount in excess of the PCN-excess-rate.
• Excess-traffic-marking: the setting of the header in a PCN-packet to a specific encoding, based on indications from the excess-traffic-meter.
• 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.
• 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.
• 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.
• PCN-admissible-rate: the rate of PCN-traffic on a link up to which PCN admission control should accept new PCN-flows.
• 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:

• 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 aware of ingress-egress-aggregates. The functionality is also done by PCN-ingress-nodes for their outgoing interfaces (ie those 'inside' the PCN-domain).
• 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 not 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:

• 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, and not per flow. There are two algorithms, one for threshold-metering and one for excess-traffic-metering. The meters trigger PCN-marking as necessary.
• 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 [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information (work in progress),” Oct 2008.), 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 [Moncaster08] (, “A three state extended PCN encoding scheme (work in progress),” June 2008.)) and/or set the ECN field to values other than 11 (eg as in [Menth08‑2] (, “PCN Encoding for Packet-Specific Dual Marking (PSDM) (work in progress),” July 2008.)).

In a PCN-domain the operator may have two or three encoding states available. The baseline encoding provides two encoding states (not PCN-marked, PCN-marked), whilst extended encodings can provide three encoding states (not PCN-marked, threshold-marked, 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 whether to 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 needs 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 [PCN08‑2] (, “Metering and marking behaviour of PCN-nodes (work in progress),” Oct 2008.) for further discussion.

The objective of threshold-marking, as triggerd by the threshold-metering algorithm, is to threshold-mark all PCN-packets whenever the 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-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 [PCN08‑2] (, “Metering and marking behaviour of PCN-nodes (work in progress),” Oct 2008.).

Admission and termination approaches are detailed and compared in [Charny07‑1] (, “Comparison of Proposed PCN Approaches (work in progress),” November 2007.) and [Menth08‑3] (, “PCN-Based Admission Control and Flow Termination,” 2008.). 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):

• 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 admitted, and 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".
• 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 set-up packet (eg RSVP PATH). Another is that after one (or several) threshold-marks then 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 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):

• 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.
• Another approach instead measures the rate of excess-traffic-marked traffic and terminates this amount of traffic. This terminates less traffic than the previous bullet if some nodes are dropping PCN-traffic.
• 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] (, “Edge-Assisted Marked Flow Termination (work in progress),” February 2008.).)

Since flow termination is designed for "abnormal" circumstances, it is quite likely that some PCN-nodes are congested and hence 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 [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information (work in progress),” Oct 2008.), then an operator has three options (others might be possible):

• admission control only: PCN-marking means threshold-marking, ie only the threshold-metering algorithm triggers PCN-marking. Only PCN admission control is available.
• 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.
• 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] (, “Pre-Congestion Notification Using Single Marking for Admission and Termination (work in progress),” November 2007.) describes how both admission control and flow termination can be triggered in this case and also gives some of the pros and cons of this approach. The main downside is that admission control is less accurate.

                          ==   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] (, “Pre-Congestion Notification Using Single Marking for Admission and Termination (work in progress),” November 2007.). 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, for instance; [Lefaucheur06] (, “RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification (PCN) (work in progress),” June 2006.) describes the extensions needed for RSVP.

3.5.  PCN-traffic

The following are some high-level points about how PCN works:

• 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.
• It is not advised to have non PCN-traffic that competes for the same capacity as PCN-traffic but, if there is such traffic, there needs to be a mechanism to limit it. “Capacity” means the forwarding bandwidth on a link; “competes” means that non PCN-packets will delay PCN-packets in the queue for the link. Hence more non PCN-traffic results in poorer QoS for PCN. Further, the unpredictable amount of non PCN-traffic makes the PCN mechanisms less accurate and so reduces PCN’s ability to protect the QoS of admitted PCN-flows
• Two examples of such non PCN-traffic (ie that competes for the same capacity as 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 [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information (work in progress),” Oct 2008.) and there is non-PCN voice-admit traffic in the PCN-domain).

• If there is such non PCN-traffic (ie that competes for the same capacity as 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 non PCN-traffic contributes to the PCN meters (ie is metered by the threshold-marking and excess-traffic-marking algorithms).

• There will be non PCN-traffic that doesn’t compete for the same capacity 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.
• The 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] (Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.). A particular PCN encoding scheme needs to describe how it meets the guidelines of BCP 124 [RFC4774] (Floyd, S., “Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field,” November 2006.) for specifying alternative semantics for the ECN field. In summary the approach is to:

• use a DSCP to allow PCN-nodes to distinguish PCN-traffic that uses the alternative ECN semantics;
• define these semantics for use within a controlled region, the PCN-domain;
• 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 [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information (work in progress),” Oct 2008.), 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'.

4.  Detailed Functional architecture

This section is intended to provide a systematic summary of the new functional architecture in the PCN-domain. First it describes functions needed at the three specific types of PCN-node; these are data plane functions and are in addition to their normal router functions. Then it describes further functionality needed for both flow admission control and flow termination; these are signalling and decision-making functions, and there are various possibilities for where the functions are physically located. The section is split into:

1. functions needed at PCN-interior-nodes
2. functions needed at PCN-ingress-nodes
3. functions needed at PCN-egress-nodes
4. other functions needed for flow admission control
5. other functions needed for flow termination control

Note: Probing is covered in the Appendix.

The section then discusses some other detailed topics:

1. addressing
2. tunnelling
3. fault handling

4.1.  PCN-interior-node functions

Each link of the PCN-domain is configured with the following functionality:

• Behaviour aggregate classification – determine whether an incoming packet is a PCN-packet or not.
• PCN-meter – measure the ‘amount of PCN-traffic’. The measurement is made on the overall PCN-traffic, and not per flow. Algorithms determine whether to indicate to the PCN-marking functionality that packets should be PCN-marked.
• PCN-mark – as triggered by indications from the PCN-meter functionality, if necessary PCN-mark packets wth the appropiate encoding.
• Drop - if the queue overflows then naturally packets are dropped. In addition, the link may be configured with a maximum rate for PCN-traffic (below the physical link rate), above which PCN-packets are dropped.

The functions are defined in [PCN08‑2] (, “Metering and marking behaviour of PCN-nodes (work in progress),” Oct 2008.) and the baseline encoding in [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information (work in progress),” Oct 2008.) (extended encodings are to be defined in other documents).

                                       +---------+   Result
                                    +->|Threshold|-------+
                                    |  |  Meter  |       |
                                    |  +---------+       V
         +----------+   +- - - - -+  |                +------+
         |   BA     |   |         |  |                |      |    Marked
Packet =>|Classifier|==>| Dropper |==?===============>|Marker|==> Packet
Stream   |          |   |         |  |                |      |    Stream
         +----------+   +- - - - -+  |                +------+
                                    |  +---------+       ^
                                    |  | Excess  |       |
                                    +->| Traffic |-------+
                                       |  Meter  |   Result
                                       +---------+

Figure 4: Schematic of PCN-interior-node functionality

4.2.  PCN-ingress-node functions

Each ingress link of the PCN-domain is configured with the following functionality:

• Packet classification – determine whether an incoming packet is part of a previously admitted flow, by using a filter spec (eg DSCP, source and destination addresses, port numbers, and protocol).
• Police - police, by dropping, any packets received with a DSCP indicating PCN transport that do not belong to an admitted flow. (A prospective PCN-flow that is rejected could be blocked or admitted into a lower priority behaviour aggregate.) Similarly, police packets that are part of a previously admitted flow, to check that the flow keeps to the agreed rate or flowspec (eg [RFC1633] (Braden, B., Clark, D., and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” June 1994.) for a microflow and its NSIS equivalent).
• PCN-colour – set the DSCP and ECN fields appropriately for the PCN-domain, for example as in [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information (work in progress),” Oct 2008.).
• Meter - some approaches to flow termination require the PCN-ingress-node to measure the (aggregate) rate of PCN-traffic towards a particular PCN-egress-node.

The first two are policing functions, needed to make sure that PCN-packets admitted into the PCN-domain belong to a flow that has been admitted and to ensure that the flow keeps to the flowspec agreed (eg doesn't exceed an agreed maximum rate and is inelastic traffic). Installing the filter spec will typically be done by the signalling protocol, as will re-installing the filter, for example after a re-route that changes the PCN-ingress-node (see [Briscoe06] (, “An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a Diffserv Region (work in progress),” October 2006.) for an example using RSVP). PCN-colouring allows the rest of the PCN-domain to recognise PCN-packets.

4.3.  PCN-egress-node functions

Each egress link of the PCN-domain is configured with the following functionality:

• Packet classify – determine which PCN-ingress-node a PCN-packet has come from.
• Meter – "measure PCN-traffic" or "monitor PCN-marks".
• PCN-colour – for PCN-packets, set the DSCP and ECN fields to the appropriate values for use outside the PCN-domain.

The metering functionality of course depends on whether it is targeted at admission control or flow termination. Alternatives involve the PCN-egress-node "measuring" as an aggregate (ie not per flow) all PCN-packets from a particular PCN-ingress-node, or "monitoring" the PCN-traffic and reacting to one (or several) PCN-marked packets. For PCN-colouring, [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information (work in progress),” Oct 2008.) specifies that the PCN-egress-node re-sets the ECN field to 00; other encodings may define different behaviour.

4.4.  Admission control functions

As well as the functions covered above, other specific admission control functions need to be performed (others might be possible):

• Make decision about admission – based on the output of the PCN-egress-node's meter function. In the case where it "measures PCN-traffic", the measured traffic on the ingress-egress-aggregate is compared with some reference level. In the case where it "monitors PCN-marks", then the decision is based on whether one (or several) packets is (are) PCN-marked or not (eg the RSVP PATH message). In either case, the admission decision also takes account of policy and application layer requirements [RFC2753] (Yavatkar, R., Pendarakis, D., and R. Guerin, “A Framework for Policy-based Admission Control,” January 2000.).
• Communicate decision about admission - signal the decision to the node making the admission control request (which may be outside the PCN-domain), and to the policer (PCN-ingress-node function) for enforcement of the decision.

There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used):

• The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node.
• The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress-node. The rationale is that the PCN-egress-node naturally has the necessary information about the amount of PCN-marks on the ingress-egress-aggregate, but the PCN-ingress-node is the policy enforcement point [RFC2753] (Yavatkar, R., Pendarakis, D., and R. Guerin, “A Framework for Policy-based Admission Control,” January 2000.), which polices incoming traffic to ensure it is part of an admitted PCN-flow.
• The decision is made at the PCN-ingress-node, which requires that the PCN-egress-node signals PCN-feedback-information to the PCN-ingress-node. For example, it could signal the current fraction of PCN-traffic that is PCN-marked.
• The decision is made at a centralised node (see Appendix).

Note: Admission control functionality is not performed by normal PCN-interior-nodes.

4.5.  Flow termination functions

As well as the functions covered above, other specific termination control functions need to be performed (others might be possible):

• PCN-meter at PCN-egress-node - similarly to flow admission, there are two types of possibilities: to "measure PCN-traffic” on the ingress-egress-aggregate, and to "monitor PCN-marks" and react to one (or several) PCN-marks.
• (if required) PCN-meter at PCN-ingress-node - make “measurements of PCN-traffic” being sent towards a particular PCN-egress-node; again, this is done for the ingress-egress-aggregate and not per flow.
• (if required) Communicate PCN-feedback-information to the node that makes the flow termination decision. For example, as in [Briscoe06] (, “An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a Diffserv Region (work in progress),” October 2006.), communicate the PCN-egress-node's measurements to the PCN-ingress-node.
• Make decision about flow termination – use the information from the PCN-meter(s) to decide which PCN-flow or PCN-flows to terminate. The decision takes account of policy and application layer requirements [RFC2753] (Yavatkar, R., Pendarakis, D., and R. Guerin, “A Framework for Policy-based Admission Control,” January 2000.).
• Communicate decision about flow termination - signal the decision to the node that is able to terminate the flow (which may be outside the PCN-domain), and to the policer (PCN-ingress-node function) for enforcement of the decision.

There are various possibilities for how the functionality could be distributed, similar to those discussed above in the Admission control section.

Note: Flow termination functionality is not performed by normal PCN-interior-nodes.

4.6.  Addressing

PCN-nodes may need to know the address of other PCN-nodes. Note: in all cases PCN-interior-nodes don't need to know the address of any other PCN-nodes (except as normal their next hop neighbours, for routing purposes).

The PCN-egress-node needs to know the address of the PCN-ingress-node associated with a flow, at a minimum so that the PCN-ingress-node can be informed to enforce the admission decision (and any flow termination decision) through policing. There are various possibilities for how the PCN-egress-node can do this, ie associate the received packet to the correct ingress-egress-aggregate. It is not the intention of this document to mandate a particular mechanism.

• The addressing information can be gathered from signalling. For example, regular processing of an RSVP PATH message, as the PCN-ingress-node is the previous RSVP hop (PHOP) ([Lefaucheur06] (, “RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification (PCN) (work in progress),” June 2006.)). Or the PCN-ingress-node could signal its address to the PCN-egress-node.
• Always tunnel PCN-traffic across the PCN-domain. Then the PCN-ingress-node's address is simply the source address of the outer packet header. The PCN-ingress-node needs to learn the address of the PCN-egress-node, either by manual configuration or by one of the automated tunnel endpoint discovery mechanisms (such as signalling or probing over the data route, interrogating routing or using a centralised broker).

4.7.  Tunnelling

Tunnels may originate and/or terminate within a PCN-domain (eg IP over IP, IP over MPLS). It is important that the PCN-marking of any packet can potentially influence PCN’s flow admission control and termination – it shouldn’t matter whether the packet happens to be tunnelled at the PCN-node that PCN-marks the packet, or indeed whether it’s decapsulated or encapsulated by a subsequent PCN-node. This suggests that the “uniform conceptual model” described in [RFC2983] (Black, D., “Differentiated Services and Tunnels,” October 2000.) should be re-applied in the PCN context. In line with this and the approach of [RFC4303] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) and [Briscoe08‑2] (, “Tunnelling of Congestion Notification (work in progress),” July 2008.), the following rule is applied if encapsulation is done within the PCN-domain:

• any PCN-marking is copied into the outer header

Note: A tunnel will not provide this behaviour if it complies with [RFC3168] (Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.) tunnelling in either mode, but it will if it complies with [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) IPSec tunnelling.

Similarly, in line with the “uniform conceptual model” of [RFC2983] (Black, D., “Differentiated Services and Tunnels,” October 2000.), the “full-functionality option” of [RFC3168] (Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.), and [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.), the following rule is applied if decapsulation is done within the PCN-domain:

• if the outer header's marking state is more severe then it is copied onto the inner header.

Note: the order of increasing severity is: not PCN-marked; threshold-marked; excess-traffic-marked.

An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to PCN-egress-nodes. The PCN-marks shouldn’t be visible outside the PCN-domain, which can be achieved by the PCN-egress-node doing the PCN-colouring function (Section 4.3) after all the other (PCN and tunnelling) functions. The potential reasons for doing such tunnelling are: the PCN-egress-node then automatically knows the address of the relevant PCN-ingress-node for a flow; even if ECMP is running, all PCN-packets on a particular ingress-egress-aggregate follow the same path. (ECMP: Equal Cost Multi-Path, Section 6.4.) But it also has drawbacks, for example the additional overhead in terms of bandwidth and processing, and the cost of setting up a mesh of tunnels between PCN-boundary-nodes (there is an N^2 scaling issue).

Potential issues arise for a “partially PCN-capable tunnel”, ie where only one tunnel endpoint is in the PCN domain:

1. The tunnel originates outside a PCN-domain and ends inside it. If the packet arrives at the tunnel ingress with the same encoding as used within the PCN-domain to indicate PCN-marking, then this could lead the PCN-egress-node to falsely measure pre-congestion.
2. The tunnel originates inside a PCN-domain and ends outside it. If the packet arrives at the tunnel ingress already PCN-marked, then it will still have the same encoding when it’s decapsulated which could potentially confuse nodes beyond the tunnel egress.

In line with the solution for partially capable Diffserv tunnels in [RFC2983] (Black, D., “Differentiated Services and Tunnels,” October 2000.), the following rules are applied:

• For case (1), the tunnel egress node clears any PCN-marking on the inner header. This rule is applied before the ‘copy on decapsulation’ rule above.
• For case (2), the tunnel ingress node clears any PCN-marking on the inner header. This rule is applied after the ‘copy on encapsulation’ rule above.

Note that the above implies that one has to know, or determine, the characteristics of the other end of the tunnel as part of establishing it.

Tunnelling constraints were a major factor in the choice of the baseline encoding. As explained in [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information (work in progress),” Oct 2008.), with current tunnelling endpoints only the 11 codepoint of the ECN field survives decapsulation, and hence the baseline encoding only uses the 11 codepoint to indicate PCN-marking. Extended encoding schemes need to explain their interactions with (or assumptions about) tunnelling. A lengthy discussion of all the issues associated with layered encapsulation of congestion notification (for ECN as well as PCN) is in [Briscoe08‑2] (, “Tunnelling of Congestion Notification (work in progress),” July 2008.).

4.8.  Fault handling

If a PCN-interior-node (or one of its links) fails, then lower layer protection mechanisms or the regular IP routing protocol will eventually re-route around it. If the new route can carry all the admitted traffic, flows will gracefully continue. If instead this causes early warning of pre-congestion on the new route, then admission control based on pre-congestion notification will ensure new flows will not be admitted until enough existing flows have departed. Re-routing may result in heavy (pre-)congestion, when the flow termination mechanism will kick in.

If a PCN-boundary-node fails then we would like the regular QoS signalling protocol to be responsible for taking appropriate action. As an example [Briscoe08‑2] (, “Tunnelling of Congestion Notification (work in progress),” July 2008.) considers what happens if RSVP is the QoS signalling protocol.

5.  Operations and Management

This Section considers operations and management issues, under the FCAPS headings: the Operations and Management of Faults, Configuration, Accounting, Performance and Security. Provisioning is discussed with performance.

5.1.  Configuration Operations and Management

Threshold-metering and -marking and excess-traffic-metering and -marking are standardised in [PCN08‑2] (, “Metering and marking behaviour of PCN-nodes (work in progress),” Oct 2008.). However, more diversity in PCN-boundary-node behaviours is expected, in order to interface with diverse industry architectures. It may be possible to have different PCN-boundary-node behaviours for different ingress-egress-aggregates within the same PCN-domain.

PCN metering behaviour is enabled on either the egress or the ingress interfaces of PCN-nodes. A consistent choice must be made across the PCN-domain to ensure that the PCN mechanisms protect all links.

PCN configuration control variables fall into the following categories:

• system options (enabling or disabling behaviours)
• parameters (setting levels, addresses etc)

One possibility is that all configurable variables sit within an SNMP management framework [RFC3411] (Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” December 2002.), being structured within a defined management information base (MIB) on each node, and being remotely readable and settable via a suitably secure management protocol (SNMPv3).

Some configuration options and parameters have to be set once to 'globally' control the whole PCN-domain. Where possible, these are identified below. This may affect operational complexity and the chances of interoperability problems between equipment from different vendors.

It may be possible for an operator to configure some PCN-interior-nodes so that they don't run the PCN mechanisms, if it knows that these links will never become (pre-)congested.

5.1.1.  System options

On PCN-interior-nodes there will be very few system options:

• Whether two PCN-markings (threshold-marked and excess-traffic-marked) are enabled or only one. Typically all nodes throughout a PCN-domain will be configured the same in this respect. However, exceptions could be made. For example, if most PCN-nodes used both markings, but some legacy hardware was incapable of running two algorithms, an operator might be willing to configure these legacy nodes solely for excess-traffic-marking to enable flow termination as a back-stop. It would be sensible to place such nodes where they could be provisioned with a greater leeway over expected traffic levels.
• In the case where only one PCN-marking is enabled, all nodes must be configured to generate PCN-marks from the same meter (ie either the threshold meter or the excess traffic meter).

PCN-boundary-nodes (ingress and egress) will have more system options:

• Which of admission and flow termination are enabled. If any PCN-interior-node is configured to generate a marking, all PCN-boundary-nodes must be able to interpret that marking (which includes understanding, in a PCN-domain that uses only one type of PCN-marking, whether they are generated by PCN-interior-nodes' threshold meters or the excess traffic meters). Therefore all PCN-boundary-nodes must be configured the same in this respect.
• Where flow admission and termination decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a centralised node, see Appendix). Theoretically, this configuration choice could be negotiated for each pair of PCN-boundary-nodes, but we cannot imagine why such complexity would be required, except perhaps in future inter-domain scenarios.
• How PCN-markings are translated into admission control and flow termination decisions (see Section 3.1 and Section 3.2).

PCN-egress-nodes will have further system options:

• How the mapping should be established between each packet and its aggregate, eg by MPLS label, by IP packet filter spec; and how to take account of ECMP.
• If an equipment vendor provides a choice, there may be options to select which smoothing algorithm to use for measurements.

5.1.2.  Parameters

Like any Diffserv domain, every node within a PCN-domain will need to be configured with the DSCP(s) used to identify PCN-packets. On each interior link the main configuration parameters are the PCN-threshold-rate and PCN-excess-rate. A larger PCN-threshold-rate enables more PCN-traffic to be admitted on a link, hence improving capacity utilisation. A PCN-excess-rate set further above the PCN-threshold-rate allows greater increases in traffic (whether due to natural fluctuations or some unexpected event) before any flows are terminated, ie minimises the chances of unnecessarily triggering the termination mechanism. For instance, an operator may want to design their network so that it can cope with a failure of any single PCN-node without terminating any flows.

Setting these rates on first deployment of PCN will be very similar to the traditional process for sizing an admission controlled network, depending on: the operator's requirements for minimising flow blocking (grade of service), the expected PCN traffic load on each link and its statistical characteristics (the traffic matrix), contingency for re-routing the PCN traffic matrix in the event of single or multiple failures, and the expected load from other classes relative to link capacities [Menth07] (, “PCN-Based Resilient Network Admission Control: The Impact of a Single Bit",” 2007.). But once a domain is in operation, a PCN design goal is to be able to determine growth in these configured rates much more simply, by monitoring PCN-marking rates from actual rather than expected traffic (see Section 5.2 on Performance & Provisioning).

Operators may also wish to configure a rate greater than the PCN-excess-rate that is the absolute maximum rate that a link allows for PCN-traffic. This may simply be the physical link rate, but some operators may wish to configure a logical limit to prevent starvation of other traffic classes during any brief period after PCN-traffic exceeds the PCN-excess-rate but before flow termination brings it back below this rate.

Threshold-metering requires a threshold token bucket depth to be configured, excess-traffic-metering needs a value for the MTU (maximum size of a PCN-packet on the link) and both require setting a maximum size of their token buckets. It will be preferable for there to be rules to set defaults for these parameters, but then allow operators to change them, for instance if average traffic characteristics change over time.

The PCN-egress-node may allow configuration of the following:

• how it smooths metering of PCN-markings (eg EWMA parameters)

Whichever node makes admission and flow termination decisions will contain algorithms for converting PCN-marking levels into admission or flow termination decisions. These will also require configurable parameters, for instance:

• an admission control algorithm that is based on the fraction of marked packets will at least require a marking threshold setting above which it denies admission to new flows;
• flow termination algorithms will probably require a parameter to delay termination of any flows until it is more certain that an anomalous event is not transient;
• a parameter to control the trade-off between how quickly excess flows are terminated, and over-termination.

One particular approach, [Charny07‑2] (, “Pre-Congestion Notification Using Single Marking for Admission and Termination (work in progress),” November 2007.) would require a global parameter to be defined on all PCN-nodes, but only needs one PCN marking rate to be configured on each link. The global parameter is a scaling factor between admission and termination (the PCN-traffic rate on a link up to which flows are admitted vs the rate above which flows are terminated). [Charny07‑2] (, “Pre-Congestion Notification Using Single Marking for Admission and Termination (work in progress),” November 2007.) discusses in full the impact of this particular approach on the operation of PCN.

5.2.  Performance & Provisioning Operations and Management

Monitoring of performance factors measurable from *outside* the PCN domain will be no different with PCN than with any other packet-based flow admission control system, both at the flow level (blocking probability, etc) and the packet level (jitter [RFC3393] (Demichelis, C. and P. Chimento, “IP Packet Delay Variation Metric for IP Performance Metrics (IPPM),” November 2002.), [Y.1541] (, “Network Performance Objectives for IP-based Services,” February 2006.), loss rate [RFC4656] (Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, “A One-way Active Measurement Protocol (OWAMP),” September 2006.), mean opinion score [P.800] (, “Methods for subjective determination of transmission quality,” August 1996.), etc). The difference is that PCN is intentionally designed to indicate *internally* which exact resource(s) are the cause of performance problems and by how much.

Even better, PCN indicates which resources will probably cause problems if they are not upgraded soon. This can be achieved by the management system monitoring the total amount (in bytes) of PCN-marking generated by each queue over a period. Given possible long provisioning lead times, pre-congestion volume is the best metric to reveal whether sufficient persistent demand has occurred to warrant an upgrade. Because, even before utilisation becomes problematic, the statistical variability of traffic will cause occasional bursts of pre-congestion. This 'early warning system' decouples the process of adding customers from the provisioning process. This should cut the time to add a customer when compared against admission control provided over native Diffserv [RFC2998] (Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, “A Framework for Integrated Services Operation over Diffserv Networks,” November 2000.), because it saves having to verify the capacity planning process before adding each customer.

Alternatively, before triggering an upgrade, the long term pre-congestion volume on each link can be used to balance traffic load across the PCN-domain by adjusting the link weights of the routing system. When an upgrade to a link’s configured PCN-rates is required, it may also be necessary to upgrade the physical capacity available to other classes. But usually there will be sufficient physical capacity for the upgrade to go ahead as a simple configuration change. Alternatively, [Songhurst06] (, “Guaranteed QoS Synthesis for Admission Control with Shared Capacity,” Feburary 2006.) describes an adaptive rather than preconfigured system, where the configured PCN-threshold-rate is replaced with a high and low water mark and the marking algorithm automatically optimises how physical capacity is shared using the relative loads from PCN and other traffic classes.

All the above processes require just three extra counters associated with each PCN queue: threshold-markings, excess-traffic-markings and drop. Every time a PCN packet is marked or dropped its size in bytes should be added to the appropriate counter. Then the management system can read the counters at any time and subtract a previous reading to establish the incremental volume of each type of (pre-)congestion. Readings should be taken frequently, so that anomalous events (eg re-routes) can be distinguished from regular fluctuating demand if required.

5.3.  Accounting Operations and Management

Accounting is only done at trust boundaries so it is out of scope of this document, which is confined to intra-domain issues. Use of PCN internal to a domain makes no difference to the flow signalling events crossing trust boundaries outside the PCN-domain, which are typically used for accounting.

5.4.  Fault Operations and Management

Fault Operations and Management is about preventing faults, telling the management system (or manual operator) that the system has recovered (or not) from a failure, and about maintaining information to aid fault diagnosis.

Admission blocking and particularly flow termination mechanisms should rarely be needed in practice. It would be unfortunate if they didn't work after an option had been accidentally disabled. Therefore it will be necessary to regularly test that the live system works as intended (devising a meaningful test is left as an exercise for the operator).

Section 4 (Detailed Functional architecture) describes how the PCN architecture has been designed to ensure admitted flows continue gracefully after recovering automatically from link or node failures. The need to record and monitor re-routing events affecting signalling is unchanged by the addition of PCN to a Diffserv domain. Similarly, re-routing events within the PCN-domain will be recorded and monitored just as they would be without PCN.

PCN-marking does make it possible to record 'near-misses'. For instance, at the PCN-egress-node a 'reporting threshold' could be set to monitor how often - and for how long - the system comes close to triggering flow blocking without actually doing so. Similarly, bursts of flow termination marking could be recorded even if they are not sufficiently sustained to trigger flow termination. Such statistics could be correlated with per-queue counts of marking volume (Section 5.2) to upgrade resources in danger of causing service degradation, or to trigger manual tracing of intermittent incipient errors that would otherwise have gone unnoticed.

Finally, of course, many faults are caused by failings in the management process ('human error'): a wrongly configured address in a node, a wrong address given in a signalling protocol, a wrongly configured parameter in a queueing algorithm, a node set into a different mode from other nodes, and so on. Generally, a clean design with few configurable options ensures this class of faults can be traced more easily and prevented more often. Sound management practice at run-time also helps. For instance: a management system should be used that constrains configuration changes within system rules (eg preventing an option setting inconsistent with other nodes); configuration options should also be recorded in an offline database; and regular automatic consistency checks between live systems and the database should be performed. PCN adds nothing specific to this class of problems.

5.5.  Security Operations and Management

Security Operations and Management is about using secure operational practices as well as being able to track security breaches or near-misses at run-time. PCN adds few specifics to the general good practice required in this field [RFC4778] (Kaeo, M., “Operational Security Current Practices in Internet Service Provider Environments,” January 2007.), other than those below. The correct functions of the system should be monitored (Section 5.2) in multiple independent ways and correlated to detect possible security breaches. Persistent (pre-)congestion marking should raise an alarm (both on the node doing the marking and on the PCN-egress-node metering it). Similarly, persistently poor external QoS metrics (such as jitter or mean opinion score) should raise an alarm. The following are examples of symptoms that may be the result of innocent faults, rather than attacks, but until diagnosed they should be logged and trigger a security alarm:

• Anomalous patterns of non-conforming incoming signals and packets rejected at the PCN-ingress-nodes (eg packets already marked PCN-capable, or traffic persistently starving token bucket policers).
• PCN-capable packets arriving at a PCN-egress-node with no associated state for mapping them to a valid ingress-egress-aggregate.
• A PCN-ingress-node receiving feedback signals about the pre-congestion level on a non-existent aggregate, or that are inconsistent with other signals (eg unexpected sequence numbers, inconsistent addressing, conflicting reports of the pre-congestion level, etc).
• Pre-congestion marking arriving at a PCN-egress-node with (pre-)congestion markings focused on particular flows, rather than randomly distributed throughout the aggregate.

6.  Applicability of PCN

6.1.  Benefits

The key benefits of the PCN mechanisms are that they are simple, scalable, and robust because:

• Per flow state is only required at the PCN-ingress-nodes ("stateless core"). This is required for policing purposes (to prevent non-admitted PCN traffic from entering the PCN-domain) and so on. It is not generally required that other network entities are aware of individual flows (although they may be in particular deployment scenarios).
• Admission control is resilient: with PCN QoS is decoupled from the routing system. Hence in general admitted flows can survive capacity, routing or topology changes without additional signalling. The PCN-admissible-rate on each link can be chosen small enough that admitted traffic can still be carried after a rerouting in most failure cases [Menth07] (, “PCN-Based Resilient Network Admission Control: The Impact of a Single Bit",” 2007.). This is an important feature as QoS violations in core networks due to link failures are more likely than QoS violations due to increased traffic volume [Iyer03] (, “An approach to alleviate link overload as observed on an IP backbone,” 2003.).
• The PCN-metering behaviours only operate on the overall PCN-traffic on the link, not per flow.
• The information of these measurements is signalled to the PCN-egress-nodes by the PCN-marks in the packet headers, ie [Style] (, “Guardian Style,” 2007.) "in-band". No additional signalling protocol is required for transporting the PCN-marks. Therefore no secure binding is required between data packets and separate congestion messages.
• The PCN-egress-nodes make separate measurements, operating on the aggregate PCN-traffic from each PCN-ingress-node, ie not per flow. Similarly, signalling by the PCN-egress-node of PCN-feedback-information (which is used for flow admission and termination decisions) is at the granularity of the ingress-egress-aggregate. An alternative approach is that the PCN-egress-nodes monitor the PCN-traffic and signal PCN-feedback-information (which is used for flow admission and termination decisions) at the granularity of one (or a few) PCN-marks.
• The admitted PCN-load is controlled dynamically. Therefore it adapts as the traffic matrix changes, and also if the network topology changes (eg after a link failure). Hence an operator can be less conservative when deploying network capacity, and less accurate in their prediction of the PCN-traffic matrix.
• The termination mechanism complements admission control. It allows the network to recover from sudden unexpected surges of PCN-traffic on some links, thus restoring QoS to the remaining flows. Such scenarios are expected to be rare but not impossible. They can be caused by large network failures that redirect lots of admitted PCN-traffic to other links, or by malfunction of the measurement-based admission control in the presence of admitted flows that send for a while with an atypically low rate and then increase their rates in a correlated way.
• Flow termination can also enable an operator to be less conservative when deploying network capacity. It is an alternative to running links at low utilisation in order to protect against link or node failures. This is especially the case with SRLGs (shared risk link groups, which are links that share a resource, such as a fibre, whose failure affects all those links [RFC4216] (Zhang, R. and J. Vasseur, “MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements,” November 2005.)). Fully protecting traffic against a single SRLG failure requires low utilisation (~10%) of the link bandwidth on some links before failure [Charny08] (, “Email to PCN WG mailing list,” March 2008.).
• The PCN-supportable-rate may be set below the maximum rate that PCN-traffic can be transmitted on a link, in order to trigger termination of some PCN-flows before loss (or excessive delay) of PCN-packets occurs, or to keep the maximum PCN-load on a link below a level configured by the operator.
• Provisioning of the network is decoupled from the process of adding new customers. By contrast, with the Diffserv architecture [RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.) operators rely on subscription-time Service Level Agreements, which statically define the parameters of the traffic that will be accepted from a customer, and so the operator has to verify provision is sufficient each time a new customer is added to check that the Service Level Agreement can be fulfilled. A PCN-domain doesn't need such traffic conditioning.

6.2.  Deployment scenarios

Operators of networks will want to use the PCN mechanisms in various arrangements, for instance depending on how they are performing admission control outside the PCN-domain (users after all are concerned about QoS end-to-end), what their particular goals and assumptions are, how many PCN encoding states are available, and so on.

A PCN-domain may have three encoding states (or pedantically, an operator may choose to use up three encoding states for PCN): not PCN-marked, threshold-marked, excess-traffic-marked. Then both PCN admission control and flow termination can be supported. As illustrated in Figure 1, admission control accepts new flows until the PCN-traffic rate on the bottleneck link rises above the PCN-threshold-rate, whilst if necessary the flow termination mechanism terminates flows down to the PCN-excess-rate on the bottleneck link.

On the other hand, a PCN-domain may have two encoding states (as in [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information (work in progress),” Oct 2008.)) (or pedantically, an operator may choose to use up two encoding states for PCN): not PCN-marked, PCN-marked. Then there are three possibilities, as discussed in the following paragraphs (see also Section 3.3).

First, an operator could just use PCN's admission control, solving heavy congestion (caused by re-routing) by 'just waiting' - as sessions end, PCN-traffic naturally reduces, and meanwhile the admission control mechanism will prevent admission of new flows that use the affected links. So the PCN-domain will naturally return to normal operation, but with reduced capacity. The drawback of this approach would be that, until sufficient sessions have ended to relieve the congestion, all PCN-flows as well as lower priority services will be adversely affected.

Second, an operator could just rely for admission control on statically provisioned capacity per PCN-ingress-node (regardless of the PCN-egress-node of a flow), as is typical in the hose model of the Diffserv architecture [RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.). Such traffic conditioning agreements can lead to focused overload: many flows happen to focus on a particular link and then all flows through the congested link fail catastrophically. PCN's flow termination mechanism could then be used to counteract such a problem.

Third, both admission control and flow termination can be triggered from the single type of PCN-marking; the main downside is that admission control is less accurate [Charny07‑2] (, “Pre-Congestion Notification Using Single Marking for Admission and Termination (work in progress),” November 2007.). This possibility is illustrated in Figure 3.

Within the PCN-domain there is some flexibility about how the decision making functionality is distributed. These possibilities are outlined in Section 4.4 and also discussed elsewhere, such as in [Menth08‑3] (, “PCN-Based Admission Control and Flow Termination,” 2008.).

The flow admission and termination decisions need to be enforced through per flow policing by the PCN-ingress-nodes. If there are several PCN-domains on the end-to-end path, then each needs to police at its PCN-ingress-nodes. One exception is if the operator runs both the access network (not a PCN-domain) and the core network (a PCN-domain); per flow policing could be devolved to the access network and not done at the PCN-ingress-node. Note: to aid readability, the rest of this draft assumes that policing is done by the PCN-ingress-nodes.

PCN admission control has to fit with the overall approach to admission control. For instance [Briscoe06] (, “An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a Diffserv Region (work in progress),” October 2006.) describes the case where RSVP signalling runs end-to-end. The PCN-domain is a single RSVP hop, ie only the PCN-boundary-nodes process RSVP messages, with RSVP messages processed on each hop outside the PCN-domain, as in IntServ over Diffserv [RFC2998] (Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, “A Framework for Integrated Services Operation over Diffserv Networks,” November 2000.). It would also be possible for the RSVP signalling to be originated and/or terminated by proxies, with application-layer signalling between the end user and the proxy (eg SIP signalling with a home hub). A similar example would use NSIS signalling instead of RSVP. (NSIS: Next Steps in Signalling, [RFC3726] (Brunner, M., “Requirements for Signaling Protocols,” April 2004.).)

It is possible that a user wants its inelastic traffic to use the PCN mechanisms but also react to ECN marking outside the PCN-domain [Sarker08] (, “Usecases and Benefits of end to end ECN support in PCN Domains (work in progress),” November 2008.). Two possible ways to do this are to tunnel all PCN-packets across the PCN-domain, so that the ECN marks are carried transparently across the PCN-domain, or to use an encoding like [Moncaster08] (, “A three state extended PCN encoding scheme (work in progress),” June 2008.). Tunnelling is discussed further in Section 4.7.

Some further possible deployment models are outlined in the Appendix.

6.3.  Assumptions and constraints on scope

The scope is restricted by the following assumptions:

1. these components are deployed in a single Diffserv domain, within which all PCN-nodes are PCN-enabled and are trusted for truthful PCN-marking and transport
2. all flows handled by these mechanisms are inelastic and constrained to a known peak rate through policing or shaping
3. the number of PCN-flows across any potential bottleneck link is sufficiently large that stateless, statistical mechanisms can be effective. To put it another way, the aggregate bit rate of PCN-traffic across any potential bottleneck link needs to be sufficiently large relative to the maximum additional bit rate added by one flow. This is the basic assumption of measurement-based admission control.
4. PCN-flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope.

6.3.1.  Assumption 1: Trust and support of PCN - controlled environment

It is assumed that the PCN-domain is a controlled environment, ie all the nodes in a PCN-domain run PCN and are trusted. There are several reasons this assumption:

• The PCN-domain has to be encircled by a ring of PCN-boundary-nodes, otherwise traffic could enter a PCN-BA without being subject to admission control, which would potentially degrade the QoS of existing PCN-flows.
• Similarly, a PCN-boundary-node has to trust that all the PCN-nodes mark PCN-traffic consistently. A node not performing PCN-marking wouldn't be able to alert when it suffered pre-congestion, which potentially would lead to too many PCN-flows being admitted (or too few being terminated). Worse, a rogue node could perform various attacks, as discussed in the Security Considerations section.

One way of assuring the above two points is that the entire PCN-domain is run by a single operator. Another possibility is that there are several operators that trust each other in their handling of PCN-traffic.

Note: All PCN-nodes need to be trustworthy. However if it is known that an interface cannot become pre-congested then it is not strictly necessary for it to be capable of PCN-marking. But this must be known even in unusual circumstances, eg after the failure of some links.

6.3.2.  Assumption 2: Real-time applications

It is assumed that any variation of source bit rate is independent of the level of pre-congestion. We assume that PCN-packets come from real time applications generating inelastic traffic, ie sending packets at the rate the codec produces them, regardless of the availability of capacity [RFC4594] (Babiarz, J., Chan, K., and F. Baker, “Configuration Guidelines for DiffServ Service Classes,” August 2006.). For example, voice and video requiring low delay, jitter and packet loss, the Controlled Load Service, [RFC2211] (Wroclawski, J., “Specification of the Controlled-Load Network Element Service,” September 1997.), and the Telephony service class, [RFC4594] (Babiarz, J., Chan, K., and F. Baker, “Configuration Guidelines for DiffServ Service Classes,” August 2006.). This assumption is to help focus the effort where it looks like PCN would be most useful, ie the sorts of applications where per flow QoS is a known requirement. In other words we focus on PCN providing a benefit to inelastic traffic (PCN may or may not provide a benefit to other types of traffic).

As a consequence, it is assumed that PCN-metering and PCN-marking is being applied to traffic scheduled with the expedited forwarding per-hop behaviour, [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),” March 2002.), or a per-hop behaviour with similar characteristics.

6.3.3.  Assumption 3: Many flows and additional load

It is assumed that there are many PCN-flows on any bottleneck link in the PCN-domain (or, to put it another way, the aggregate bit rate of PCN-traffic across any potential bottleneck link is sufficiently large relative to the maximum additional bit rate added by one PCN-flow). Measurement-based admission control assumes that the present is a reasonable prediction of the future: the network conditions are measured at the time of a new flow request, however the actual network performance must be acceptable during the call some time later. One issue is that if there are only a few variable rate flows, then the aggregate traffic level may vary a lot, perhaps enough to cause some packets to get dropped. If there are many flows then the aggregate traffic level should be statistically smoothed. How many flows is enough depends on a number of factors such as the variation in each flow's rate, the total rate of PCN-traffic, and the size of the "safety margin" between the traffic level at which we start admission-marking and at which packets are dropped or significantly delayed.

No explicit assumptions are made about how many PCN-flows are in each ingress-egress-aggregate. Performance evaluation work may clarify whether it is necessary to make any additional assumption on aggregation at the ingress-egress-aggregate level.

6.3.4.  Assumption 4: Emergency use out of scope

PCN-flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc) is out of scope of this document.

6.4.  Challenges

Prior work on PCN and similar mechanisms has thrown up a number of considerations about PCN's design goals (things PCN should be good at) and some issues that have been hard to solve in a fully satisfactory manner. Taken as a whole it represents a list of trade-offs (it is unlikely that they can all be 100% achieved) and perhaps as evaluation criteria to help an operator (or the IETF) decide between options.

The following are open issues. They are mainly taken from [Briscoe06] (, “An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a Diffserv Region (work in progress),” October 2006.), which also describes some possible solutions. Note that some may be considered unimportant in general or in specific deployment scenarios or by some operators.

NOTE: Potential solutions are out of scope for this document.

• ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion is measured on a specific ingress-egress-aggregate. However, if the PCN-domain runs ECMP, then traffic on this ingress-egress-aggregate may follow several different paths - some of the paths could be pre-congested whilst others are not. There are three potential problems:
  1. over-admission: a new flow is admitted (because the pre-congestion level measured by the PCN-egress-node is sufficiently diluted by unmarked packets from non-congested paths that a new flow is admitted), but its packets travel through a pre-congested PCN-node.
  2. under-admission: a new flow is blocked (because the pre-congestion level measured by the PCN-egress-node is sufficiently increased by PCN-marked packets from pre-congested paths that a new flow is blocked), but its packets travel along an uncongested path.
  3. ineffective termination: a flow is terminated, but its path doesn't travel through the (pre-)congested router(s). Since flow termination is a 'last resort', which protects the network should over-admission occur, this problem is probably more important to solve than the other two.
• ECMP and signalling: It is possible that, in a PCN-domain running ECMP, the signalling packets (eg RSVP, NSIS) follow a different path than the data packets, which could matter if the signalling packets are used as probes. Whether this is an issue depends on which fields the ECMP algorithm uses; if the ECMP algorithm is restricted to the source and destination IP addresses, then it will not be an issue. ECMP and signalling interactions are a specific instance of a general issue for non-traditional routing combined with resource management along a path [Hancock02] (, “Slide 14 of 'NSIS: An Outline Framework for QoS Signalling',” May 2002.).
• Tunnelling: There are scenarios where tunnelling makes it difficult to determine the path in the PCN-domain. The problem, its impact, and the potential solutions are similar to those for ECMP.
• Scenarios with only one tunnel endpoint in the PCN domain may make it harder for the PCN-egress-node to gather from the signalling messages (eg RSVP, NSIS) the identity of the PCN-ingress-node.
• Bi-Directional Sessions: Many applications have bi-directional sessions - hence there are two microflows that should be admitted (or terminated) as a pair - for instance a bi-directional voice call only makes sense if microflows in both directions are admitted. However, the PCN mechanisms concern admission and termination of a single flow, and coordination of the decision for both flows is a matter for the signalling protocol and out of scope of PCN. One possible example would use SIP pre-conditions. However, there are others.
• Global Coordination: PCN makes its admission decision based on PCN-markings on a particular ingress-egress-aggregate. Decisions about flows through a different ingress-egress-aggregate are made independently. However, one can imagine network topologies and traffic matrices where, from a global perspective, it would be better to make a coordinated decision across all the ingress-egress-aggregates for the whole PCN-domain. For example, to block (or even terminate) flows on one ingress-egress-aggregate so that more important flows through a different ingress-egress-aggregate could be admitted. The problem may well be relatively insignificant.
• Aggregate Traffic Characteristics: Even when the number of flows is stable, the traffic level through the PCN-domain will vary because the sources vary their traffic rates. PCN works best when there is not too much variability in the total traffic level at a PCN-node's interface (ie in the aggregate traffic from all sources). Too much variation means that a node may (at one moment) not be doing any PCN-marking and then (at another moment) drop packets because it is overloaded. This makes it hard to tune the admission control scheme to stop admitting new flows at the right time. Therefore the problem is more likely with fewer, burstier flows.
• Flash crowds and Speed of Reaction: PCN is a measurement-based mechanism and so there is an inherent delay between packet marking by PCN-interior-nodes and any admission control reaction at PCN-boundary-nodes. For example, potentially if a big burst of admission requests occurs in a very short space of time (eg prompted by a televote), they could all get admitted before enough PCN-marks are seen to block new flows. In other words, any additional load offered within the reaction time of the mechanism must not move the PCN-domain directly from a no congestion state to overload. This 'vulnerability period' may have an impact at the signalling level, for instance QoS requests should be rate limited to bound the number of requests able to arrive within the vulnerability period.
• Silent at start: after a successful admission request the source may wait some time before sending data (eg waiting for the called party to answer). Then the risk is that, in some circumstances, PCN's measurements underestimate what the pre-congestion level will be when the source does start sending data.

7.  IANA Considerations

This memo includes no request to IANA.

8.  Security considerations

Security considerations essentially come from the Trust Assumption (Section 6.3.1), ie that all PCN-nodes are PCN-enabled and are trusted for truthful PCN-metering and PCN-marking. PCN splits functionality between PCN-interior-nodes and PCN-boundary-nodes, and the security considerations are somewhat different for each, mainly because PCN-boundary-nodes are flow-aware and PCN-interior-nodes are not.

• Because the PCN-boundary-nodes are flow-aware, they are trusted to use that awareness correctly. The degree of trust required depends on the kinds of decisions they have to make and the kinds of information they need to make them. There is nothing specific to PCN.
• The PCN-ingress-nodes police packets to ensure a PCN-flow sticks within its agreed limit, and to ensure that only PCN-flows that have been admitted contribute PCN-traffic into the PCN-domain. The policer must drop (or perhaps downgrade to a different DSCP) any PCN-packets received that are outside this remit. This is similar to the existing IntServ behaviour. Between them the PCN-boundary-nodes must encircle the PCN-domain, otherwise PCN-packets could enter the PCN-domain without being subject to admission control, which would potentially destroy the QoS of existing flows.
• PCN-interior-nodes are not flow-aware. This prevents some security attacks where an attacker targets specific flows in the data plane - for instance for DoS or eavesdropping.
• The PCN-boundary-nodes rely on correct PCN-marking by the PCN-interior-nodes. For instance a rogue PCN-interior-node could PCN-mark all packets so that no flows were admitted. Another possibility is that it doesn't PCN-mark any packets, even when it is pre-congested. More subtly, the rogue PCN-interior-node could perform these attacks selectively on particular flows, or it could PCN-mark the correct fraction overall, but carefully choose which flows it marked.
• The PCN-boundary-nodes should be able to deal with DoS attacks and state exhaustion attacks based on fast changes in per flow signalling.
• The signalling between the PCN-boundary-nodes must be protected from attacks. For example the recipient needs to validate that the message is indeed from the node that claims to have sent it. Possible measures include digest authentication and protection against replay and man-in-the-middle attacks. For the specific protocol RSVP, hop-by-hop authentication is in [RFC2747] (Baker, F., Lindell, B., and M. Talwar, “RSVP Cryptographic Authentication,” January 2000.), and [Behringer07] (, “Applicability of Keying Methods for RSVP Security (work in progress),” Nov 2007.) may also be useful.

Operational security advice is given in Section 5.5.

9.  Conclusions

The 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. The main topic is the functional architecture. It also mentions other topics like the assumptions and open issues.

10.  Acknowledgements

This document is a revised version of an earlier individual draft authored by: P. Eardley, J. Babiarz, K. Chan, A. Charny, R. Geib, G. Karagiannis, M. Menth, T. Tsou. They are therefore contributors to this document.

Thanks to those who have made comments on this document: Lachlan Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake, Ron Bonica, Scott Bradner, Bob Briscoe, Ross Callon, Jason Canon, Ken Carlberg, Anna Charny, Joachim Charzinski, Andras Csaszar, Francis Dupont, Lars Eggert, Pasi Eronen, Adrian Farrel, Ruediger Geib, Wei Gengyu, Robert Hancock, Fortune Huang, Christian Hublet, Cullen Jennings, Ingemar Johansson, Georgios Karagiannis, Hein Mekkes, Michael Menth, Toby Moncaster, Dimitri Papadimitriou, Dan Romascanu, Daisuke Satoh, Ben Strulo, Tom Taylor, Hannes Tschofenig, Tina Tsou, David Ward, Lars Westberg, Magnus Westerlund, Delei Yu. Thanks to Bob Briscoe who extensively revised the Operations and Management section.

This document is the result of discussions in the PCN WG and forerunner activity in the TSVWG. A number of previous drafts were presented to TSVWG; their authors were: B, Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley, G. Karagiannis, A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G. Liu, A. Bhargava.

11.  Comments Solicited (to be removed by RFC Editor)

Comments and questions are encouraged and very welcome. They can be addressed to the IETF PCN working group mailing list <pcn@ietf.org>.

12.  Changes (to be removed by RFC Editor)

12.1.  Changes from -10 to -11

Changes to deal with IESG comments from routing area review:

• Small clarifications to Introduction
• the term "marking" now only used to refer only to setting the codepoint (not as a shorthand for 'metering and setting the codepoint')
• Added Figure 4 (Schematic of PCN-interior-node functionality) (from [PCN08‑2] (, “Metering and marking behaviour of PCN-nodes (work in progress),” Oct 2008.)
• Appendix A brought back into the main body.
• Other minor clarifications

12.2.  Changes from -09 to -10

Changes to deal with IESG comments:

• New introduction to provide gentler introduction for the PCN novice: quick summary of PCN’s applicability; quick example of how it all hangs together in one end-to-end qos scenario; quick summary of PCN “documentation”
• OAM changed to Operations and Management
• Processed some of the minor suggestions in the Gen-ART Review by Francis Dupont
• Two wording tweaks in Sections 3.2 & 3.4 (as agreed on mailing list)
• Updated boilerplate. this draft may include material pre- Nov 10 2008 blah.

12.3.  Changes from -08 to -09

Small changes to deal with WG Chair comments:

• tweak language in various places to make it more RFC-like and less that of a scholarly work, for instance from "we propose" to "this document describes"
• tweak language in various places to make it a stand alone architecture document rather than a discussion of the PCN WG. Now only mentions WG at start of Annex.
• References: IDs are no longer referenced to by the draft name
• References: removed some of less important references to IDs

12.4.  Changes from -07 to -08

Small changes from second WG last call:

• Section 2: added definition for PCN-admissible-rate and PCN-supportable-rate. Small changes to use these terms as follows: Section 3, bullets 2 & 9; S6.1 para 1; S6.2 para1; S6.3 bullet 3; added to Figs 1 & 2.
• added the phrase "(others might be possible") before the list of approaches in Section 6.3, 7.4 & 7.5.
• added references to RFC2753 (A framework for policy-based admission control) in S7.4 & S7.5.
• throughout, updated references now that marking behaviour & baseline encoding are WG drafts.
• a few typos corrected

12.5.  Changes from -06 to -07

References re-formatted to pass ID nits. No other changes.

12.6.  Changes from -05 to -06

Minor clarifications throughout, the least insignificant are as follows:

• Section 1: added to the list of encoding states in an 'extended' scheme: "or perhaps further encoding states as suggested in draft-westberg-pcn-load-control"
• Section 2: added definition for PCN-colouring (to clarify that the term is used consistently differently from 'PCN-marking')
• Section 6.1 and 6.2: added "(others might be possible)" before the list of high level approaches for making flow admission (termination) decisions.
• Section 6.2: corrected a significant typo in 2nd bullet (more -> less)
• Section 6.3: corrected a couple of significant typos in Figure 2
• Section 6.5 (PCN-traffic) re-written for clarity. Non PCN-traffic contributing to PCN meters is now given as an example (there may be cases where don't need to meter it).
• Section 7.7: added to the text about encapsulation being done within the PCN-domain: "Note: A tunnel will not provide this behaviour if it complies with [RFC3168] tunnelling in either mode, but it will if it complies with [RFC4301] IPSec tunnelling."
• Section 7.7: added mention of [RFC4301] to the text about decapsulation being done within the PCN-domain.
• Section 8: deleted the text about design goals, since this is already covered adequately earlier eg in S3.
• Section 11: replaced the last sentence of bullet 1 by "There is nothing specific to PCN."
• Appendix: added to open issues: possibility of automatically and periodically probing.
• References: Split out Normative references (RFC2474 & RFC3246).

12.7.  Changes from -04 to -05

Minor nits removed as follows:

• Further minor changes to reflect that baseline encoding is consensus, standards track document, whilst there can be (experimental track) encoding extensions
• Traffic conditioning updated to reflect discussions in Dublin, mainly that PCN-interior-nodes don't police PCN-traffic (so deleted bullet in S7.1) and that it is not advised to have non PCN-traffic that shares the same capacity (on a link) as PCN-traffic (so added bullet in S6.5)
• Probing moved into Appendix A and deleted the 'third viewpoint' (admission control based on the marking of a single packet like an RSVP PATH message) - since this isn't really probing, and in any case is already mentioned in S6.1.
• Minor changes to S9 Operations and management - mainly to reflect that consensus on marking behaviour has simplified things so eg there are fewer parameters to configure.
• A few terminology-related errors expunged, and two pictures added to help.
• Re-phrased the claim about the natural decision point in S7.4
• Clarified that extended encoding schemes need to explain their interactions with (or assumptions about) tunnelling (S7.7) and how they meet the guidelines of BCP124 (S6.6)
• Corrected the third bullet in S6.2 (to reflect consensus about PCN-marking)

12.8.  Changes from -03 to -04

• Minor changes throughout to reflect the consensus call about PCN-marking (as reflected in [PCN08‑2] (, “Metering and marking behaviour of PCN-nodes (work in progress),” Oct 2008.)).
• Minor changes throughout to reflect the current decisions about encoding (as reflected in [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information (work in progress),” Oct 2008.) and [Moncaster08] (, “A three state extended PCN encoding scheme (work in progress),” June 2008.)).
• Introduction: re-structured to create new sections on Benefits, Deployment scenarios and Assumptions.
• Introduction: Added pointers to other PCN documents.
• Terminology: changed PCN-lower-rate to PCN-threshold-rate and PCN-upper-rate to PCN-excess-rate; excess-rate-marking to excess-traffic-marking.
• Benefits: added bullet about SRLGs.
• Deployment scenarios: new section combining material from various places within the document.
• S6 (high level functional architecture): re-structured and edited to improve clarity, and reflect the latest PCN-marking and encoding drafts.
• S6.4: added claim that the most natural place to make an admission decision is a PCN-egress-node.
• S6.5: updated the bullet about non-PCN-traffic that uses the same DSCP as PCN-traffic.
• S6.6: added a section about backwards compatibility with respect to [RFC4774] (Floyd, S., “Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field,” November 2006.).
• Appendix A: added bullet about end-to-end PCN.
• Probing: moved to Appendix B.
• Other minor clarifications, typos etc.

12.9.  Changes from -02 to -03

• Abstract: Clarified by removing the term 'aggregated'. Follow-up clarifications later in draft: S1: expanded PCN-egress-nodes bullet to mention case where the PCN-feedback-information is about one (or a few) PCN-marks, rather than aggregated information; S3 clarified PCN-meter; S5 minor changes; conclusion.
• S1: added a paragraph about how the PCN-domain looks to the outside world (essentially it looks like a Diffserv domain).
• S2: tweaked the PCN-traffic terminology bullet: changed PCN traffic classes to PCN behaviour aggregates, to be more in line with traditional Diffserv jargon (-> follow-up changes later in draft); included a definition of PCN-flows (and corrected a couple of 'PCN microflows' to 'PCN-flows' later in draft)
• S3.5: added possibility of downgrading to best effort, where PCN-packets arrive at PCN-ingress-node already ECN marked (CE or ECN nonce)
• S4: added note about whether talk about PCN operating on an interface or on a link. In S8.1 (OAM) mentioned that PCN functionality needs to be configured consistently on either the ingress or the egress interface of PCN-nodes in a PCN-domain.
• S5.2: clarified that signalling protocol installs flow filter spec at PCN-ingress-node (& updates after possible re-route)
• S5.6: addressing: clarified
• S5.7: added tunnelling issue of N^2 scaling if you set up a mesh of tunnels between PCN-boundary-nodes
• S7.3: Clarified the "third viewpoint" of probing (always probe).
• S8.1: clarified that SNMP is only an example; added note that an operator may be able to not run PCN on some PCN-interior-nodes, if it knows that these links will never become (pre-)congested; added note that it may be possible to have different PCN-boundary-node behaviours for different ingress-egress-aggregates within the same PCN-domain.
• Appendix: Created an Appendix about "Possible work items beyond the scope of the current PCN WG Charter". Material moved from near start of S3 and elsewhere throughout draft. Moved text about centralised decision node to Appendix.
• Other minor clarifications.

12.10.  Changes from -01 to -02

• S1: Benefits: provisioning bullet extended to stress that PCN does not use RFC2475-style traffic conditioning.
• S1: Deployment models: mentioned, as variant of PCN-domain extending to end nodes, that may extend to LAN edge switch.
• S3.1: Trust Assumption: added note about not needing PCN-marking capability if known that an interface cannot become pre-congested.
• S4: now divided into sub-sections
• S4.1: Admission control: added second proposed method for how to decide to block new flows (PCN-egress-node receives one (or several) PCN-marked packets).
• S5: Probing sub-section removed. Material now in new S7.
• S5.6: Addressing: clarified how PCN-ingress-node can discover address of PCN-egress-node
• S5.6: Addressing: centralised node case, added that PCN-ingress-node may need to know address of PCN-egress-node
• S5.8: Tunnelling: added case of "partially PCN-capable tunnel" and degraded bullet on this in S6 (Open Issues)
• S7: Probing: new section. Much more comprehensive than old S5.5.
• S8: Operations and Management: substantially revised.
• other minor changes not affecting semantics

12.11.  Changes from -00 to -01

In addition to clarifications and nit squashing, the main changes are:

• S1: Benefits: added one about provisioning (and contrast with Diffserv SLAs)
• S1: Benefits: clarified that the objective is also to stop PCN-packets being significantly delayed (previously only mentioned not dropping packets)
• S1: Deployment models: added one where policing is done at ingress of access network and not at ingress of PCN-domain (assume trust between networks)
• S1: Deployment models: corrected MPLS-TE to MPLS
• S2: Terminology: adjusted definition of PCN-domain
• S3.5: Other assumptions: corrected, so that two assumptions (PCN-nodes not performing ECN and PCN-ingress-node discarding arriving CE packet) only apply if the PCN WG decides to encode PCN-marking in the ECN-field.
• S4 & S5: changed PCN-marking algorithm to marking behaviour
• S4: clarified that PCN-interior-node functionality applies for each outgoing interface, and added clarification: "The functionality is also done by PCN-ingress-nodes for their outgoing interfaces (ie those 'inside' the PCN-domain)."
• S4 (near end): altered to say that a PCN-node "should" dedicate some capacity to lower priority traffic so that it isn't starved (was "may")
• S5: clarified to say that PCN functionality is done on an 'interface' (rather than on a 'link')
• S5.2: deleted erroneous mention of service level agreement
• S5.5: Probing: re-written, especially to distinguish probing to test the ingress-egress-aggregate from probing to test a particular ECMP path.
• S5.7: Addressing: added mention of probing; added that in the case where traffic is always tunnelled across the PCN-domain, add a note that he PCN-ingress-node needs to know the address of the PCN-egress-node.
• S5.8: Tunnelling: re-written, especially to provide a clearer description of copying on tunnel entry/exit, by adding explanation (keeping tunnel encaps/decaps and PCN-marking orthogonal), deleting one bullet ("if the inner header's marking state is more sever then it is preserved" - shouldn't happen), and better referencing of other IETF documents.
• S6: Open issues: stressed that "NOTE: Potential solutions are out of scope for this document" and edited a couple of sentences that were close to solution space.
• S6: Open issues: added one about scenarios with only one tunnel endpoint in the PCN domain .
• S6: Open issues: ECMP: added under-admission as another potential risk
• S6: Open issues: added one about "Silent at start"
• S10: Conclusions: a small conclusions section added

13.  References

13.1. Normative References

13.2. Informative References

Appendix A.  Possible future work items

This section mentions some topics that are outside the PCN WG's current charter, but which have been mentioned as areas of interest. They might be work items for: the PCN WG after a future re-chartering; some other IETF WG; another standards body; an operator-specific usage that is not standardised.

NOTE: it should be crystal clear that this section discusses possibilities only.

The first set of possibilities relate to the restrictions described in Section 6.3:

• a single PCN-domain encompasses several autonomous systems that do not trust each other, perhaps by using a mechanism like re-PCN, [Briscoe08‑1] (, “Emulating Border Flow Policing using Re-PCN on Bulk Data (work in progress),” Sept 2008.).
• not all the nodes run PCN. For example, the PCN-domain is a multi-site enterprise network. The sites are connected by a VPN tunnel; although PCN doesn't operate inside the tunnel, the PCN mechanisms still work properly because of the good QoS on the virtual link (the tunnel). Another example is that PCN is deployed on the general Internet (ie widely but not universally deployed).
• applying the PCN mechanisms to other types of traffic, ie beyond inelastic traffic. For instance, applying the PCN mechanisms to traffic scheduled with the Assured Forwarding per-hop behaviour. One example could be flow-rate adaptation by elastic applications that adapt according to the pre-congestion information.
• the aggregation assumption doesn't hold, because the link capacity is too low. Measurement-based admission control is less accurate, with a greater risk of over-admission for instance.
• the applicability of PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.)

Other possibilities include:

• Probing. This is discussed in Section A.1 below.
• The PCN-domain extends to the end users. The scenario is described in [Babiarz06] (, “SIP Controlled Admission and Preemption (work in progress),” Oct 2006.). The end users need to be trusted to do their own policing. If there is sufficient traffic, then the aggregation assumption may hold. A variant is that the PCN-domain extends out as far as the LAN edge switch.
• indicating pre-congestion through signalling messages rather than in-band (in the form of PCN-marked packets)
• the decision-making functionality is at a centralised node rather than at the PCN-boundary-nodes. This requires that the PCN-egress-node signals PCN-feedback-information to the centralised node, and that the centralised node signals to the PCN-ingress-node the decision about admission (or termination). It may need the centralised node and the PCN-boundary-nodes to be configured with each other's addresses. The centralised case is described further in [Tsou08] (, “Applicability Statement for the Use of Pre-Congestion Notification in a Resource-Controlled Network (work in progress),” November 2008.).
• Signalling extensions for specific protocols (eg RSVP, NSIS). For example: the details of how the signalling protocol installs the flowspec at the PCN-ingress-node for an admitted PCN-flow; and how the signalling protocol carries the PCN-feedback-information. Perhaps also for other functions such as: coping with failure of a PCN-boundary-node ([Briscoe06] (, “An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a Diffserv Region (work in progress),” October 2006.) considers what happens if RSVP is the QoS signalling protocol); establishing a tunnel across the PCN-domain if it is necessary to carry ECN marks transparently.
• Policing by the PCN-ingress-node may not be needed if the PCN-domain can trust that the upstream network has already policed the traffic on its behalf.
• PCN for Pseudowire: PCN may be used as a congestion avoidance mechanism for edge to edge pseudowire emulations [PWE3‑08] (, “Pseudowire Congestion Control Framework (work in progress),” May 2008.).
• PCN for MPLS: [RFC3270] (Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, “Multi-Protocol Label Switching (MPLS) Support of Differentiated Services,” May 2002.) defines how to support the Diffserv architecture in MPLS networks (Multi-protocol label switching). [RFC5129] (Davie, B., Briscoe, B., and J. Tay, “Explicit Congestion Marking in MPLS,” January 2008.) describes how to add PCN for admission control of microflows into a set of MPLS aggregates. PCN-marking is done in MPLS's EXP field (which [RFC5462] (Andersson, L. and R. Asati, “Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field,” February 2009.) re-names the Class of Service (CoS) field).
• PCN for Ethernet: Similarly, it may be possible to extend PCN into Ethernet networks, where PCN-marking is done in the Ethernet header. NOTE: Specific consideration of this extension is outside the IETF's remit.

A.1.  Probing

A.1.1.  Introduction

Probing is a potential mechanism to assist admission control.

PCN’s admission control, as described so far, is essentially a reactive mechanism where the PCN-egress-node monitors the pre-congestion level for traffic from each PCN-ingress-node; if the level rises then it blocks new flows on that ingress-egress-aggregate. However, it’s possible that an ingress-egress-aggregate carries no traffic, and so the PCN-egress-node can’t make an admission decision using the usual method described earlier.

One approach is to be “optimistic” and simply admit the new flow. However it’s possible to envisage a scenario where the traffic levels on other ingress-egress-aggregates are already so high that they’re blocking new PCN-flows, and admitting a new flow onto this 'empty' ingress-egress-aggregate adds extra traffic onto a link that is already pre-congested – which may ‘tip the balance’ so that PCN’s flow termination mechanism is activated or some packets are dropped. This risk could be lessened by configuring on each link sufficient ‘safety margin’ above the PCN-threshold-rate.

An alternative approach is to make PCN a more proactive mechanism. The PCN-ingress-node explicitly determines, before admitting the prospective new flow, whether the ingress-egress-aggregate can support it. This can be seen as a “pessimistic” approach, in contrast to the “optimism” of the approach above. It involves probing: a PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level that the flow would experience.

One possibility is that a probe packet is just a dummy data packet, generated by the PCN-ingress-node and addressed to the PCN-egress-node.

A.1.2.  Probing functions

The probing functions are:

• Make decision that probing is needed. As described above, this is when the ingress-egress-aggregate (or the ECMP path - Section 6.4) carries no PCN-traffic. An alternative is always to probe, ie probe before admitting every PCN-flow.
• (if required) Communicate the request that probing is needed – the PCN-egress-node signals to the PCN-ingress-node that probing is needed
• (if required) Generate probe traffic - the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-metering algorithm; for example an excess-traffic-metering algorithm triggers fewer PCN-marks than a threshold-metering algorithm, and so will need more probe packets.
• Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets are handled the same as (ordinary data) PCN-packets, in terms of routing, scheduling and PCN-marking.
• Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain.

A.1.3.  Discussion of rationale for probing, its downsides and open issues

It is an unresolved question whether probing is really needed, but two viewpoints have been put forward as to why it is useful. The first is perhaps the most obvious: there is no PCN-traffic on the ingress-egress-aggregate. The second assumes that multipath routing ECMP is running in the PCN-domain. We now consider each in turn.

The first viewpoint assumes the following:

• There is no PCN-traffic on the ingress-egress-aggregate (so a normal admission decision cannot be made).
• Simply admitting the new flow has a significant risk of leading to overload: packets dropped or flows terminated.

On the former bullet, [Eardley07] (, “Email to PCN WG mailing list,” October 2007.) suggests that, during the future busy hour of a national network with about 100 PCN-boundary-nodes, there are likely to be significant numbers of aggregates with very few flows under nearly all circumstances.

The latter bullet could occur if new flows start on many of the empty ingress-egress-aggregates, which together overload a link in the PCN-domain. To be a problem this would probably have to happen in a short time period (flash crowd) because, after the reaction time of the system, other (non-empty) ingress-egress-aggregates that pass through the link will measure pre-congestion and so block new flows. Also, flows naturally end anyway.

The downsides of probing for this viewpoint are:

• Probing adds delay to the admission control process.
• Sufficient probing traffic has to be generated to test the pre-congestion level of the ingress-egress-aggregate. But the probing traffic itself may cause pre-congestion, causing other PCN-flows to be blocked or even terminated - and in the flash crowd scenario there will be probing on many ingress-egress-aggregates.

The second viewpoint applies in the case where there is multipath routing (ECMP) in the PCN-domain. Note that ECMP is often used on core networks. There are two possibilities:

(1) If admission control is based on measurements of the ingress-egress-aggregate, then the viewpoint that probing is useful assumes:

• there’s a significant chance that the traffic is unevenly balanced across the ECMP paths, and hence there’s a significant risk of admitting a flow that should be blocked (because it follows an ECMP path that is pre-congested) or blocking a flow that should be admitted.
• Note: [Charny07‑3] (, “Email to PCN WG mailing list,” November 2007.) suggests unbalanced traffic is quite possible, even with quite a large number of flows on a PCN-link (eg 1000) when Assumption 3 (aggregation) is likely to be satisfied.

(2) If admission control is based on measurements of pre-congestion on specific ECMP paths, then the viewpoint that probing is useful assumes:

• There is no PCN-traffic on the ECMP path on which to base an admission decision.
• Simply admitting the new flow has a significant risk of leading to overload.
• The PCN-egress-node can match a packet to an ECMP path.
• Note: This is similar to the first viewpoint and so similarly could occur in a flash crowd if a new flow starts more-or-less simultaneously on many of the empty ECMP paths. Because there are several (sometimes many) ECMP paths between each pair of PCN-boundary-nodes, it’s presumably more likely that an ECMP path is ‘empty’ than an ingress-egress-aggregate is. To constrain the number of ECMP paths, a few tunnels could be set-up between each pair of PCN-boundary-nodes. Tunnelling also solves the issue in the bullet immediately above (which is otherwise hard because an ECMP routing decision is made independently on each node).

The downsides of probing for this viewpoint are:

• Probing adds delay to the admission control process.
• Sufficient probing traffic has to be generated to test the pre-congestion level of the ECMP path. But there’s the risk that the probing traffic itself may cause pre-congestion, causing other PCN-flows to be blocked or even terminated.
• The PCN-egress-node needs to consume the probe packets to ensure they don’t travel beyond the PCN-domain, since they might confuse the destination end node. This is non-trivial, since probe packets are addressed to the destination end node, in order to test the relevant ECMP path (ie they are not addressed to the PCN-egress-node, unlike the first viewpoint above).

The open issues associated with this viewpoint include:

• What rate and pattern of probe packets does the PCN-ingress-node need to generate, so that there’s enough traffic to make the admission decision?
• What difficulty does the delay (whilst probing is done), and possible packet drops, cause applications?
• Can the delay be alleviated by automatically and periodically probing on the ingress-egress-aggregate? Or does this add too much overhead?
• Are there other ways of dealing with the flash crowd scenario? For instance, by limiting the rate at which new flows are admitted; or perhaps by a PCN-egress-node blocking new flows on its empty ingress-egress-aggregates when its non-empty ones are pre-congested.
• (Second viewpoint only) How does the PCN-egress-node disambiguate probe packets from data packets (so it can consume the former)? The PCN-egress-node must match the characteristic setting of particular bits in the probe packet’s header or body – but these bits must not be used by any PCN-interior-node’s ECMP algorithm. In the general case this isn’t possible, but it should be possible for a typical ECMP algorithm (which examines: the source and destination IP addresses and port numbers, the protocol ID, and the DSCP).

Author's Address