RFC 6661

Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation

📅 published July 2012, from ietf

RFC 6661 ✨

Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation 🎀

okay so this one is from the IETF (Internet Engineering Task Force) 💅. It's an Experimental doc, not a Standards Track spec, and it was published in July 2012. The authors are A. Charny, F. Huang, G. Karagiannis, M. Menth, and T. Taylor (Ed.). Charny, Huang, and Taylor are at Huawei Technologies, Karagiannis is at the University of Twente, and Menth is at the University of Tuebingen. The ISSN is 2070-1721. It doesn't obsolete or update any other RFCs, so it's a standalone vibe 🦋

Abstract 🌸

okay so PCN (Pre-Congestion Notification) is a way to protect the quality of service for inelastic traffic that's been admitted into a Diffserv domain 💖 The big-picture architecture is in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain, and this specific one is a form of measurement-based load control that uses three PCN marking states: not-marked, threshold-marked, and excess-traffic-marked. People informally call it the Controlled Load (CL) PCN-boundary-node behavior ✨

Status of This Memo 🧚

Not an Internet Standards Track spec, fr fr. It's published so people can examine it, try it out in experimental implementations, and evaluate it 🔬

It defines an Experimental Protocol for the Internet community. It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🙈

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6661 🍓

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read these, bestie, because they explain your rights and restrictions for this document 🫶 Any Code Components pulled out of this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 💅

Table of Contents 🎀

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
  1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
2.  [CL-Specific] Assumed Core Network Behavior for CL . . . . . .  8
3.  Node Behaviors . . . . . . . . . . . . . . . . . . . . . . . .  9
  3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  9
  3.2.  Behavior of the PCN-Egress-Node  . . . . . . . . . . . . . 10
    3.2.1.  Data Collection  . . . . . . . . . . . . . . . . . . . 10
    3.2.2.  Reporting the PCN Data . . . . . . . . . . . . . . . . 11
    3.2.3.  Optional Report Suppression  . . . . . . . . . . . . . 11
  3.3.  Behavior at the Decision Point . . . . . . . . . . . . . . 12
    3.3.1.  Flow Admission . . . . . . . . . . . . . . . . . . . . 12
    3.3.2.  Flow Termination . . . . . . . . . . . . . . . . . . . 13
    3.3.3.  Decision Point Action for Missing
            PCN-Boundary-Node Reports  . . . . . . . . . . . . . . 15
  3.4.  Behavior of the Ingress Node . . . . . . . . . . . . . . . 16
  3.5.  Summary of Timers and Associated Configurable Durations  . 16
    3.5.1.  Recommended Values for the Configurable Durations  . . 18
4.  Specification of Diffserv Per-Domain Behavior  . . . . . . . . 18
  4.1.  Applicability  . . . . . . . . . . . . . . . . . . . . . . 18
  4.2.  Technical Specification  . . . . . . . . . . . . . . . . . 19
    4.2.1.  Classification and Traffic Conditioning  . . . . . . . 19
    4.2.2.  PHB Configuration  . . . . . . . . . . . . . . . . . . 19
  4.3.  Attributes . . . . . . . . . . . . . . . . . . . . . . . . 19
  4.4.  Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19
  4.5.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . 20
  4.6.  Example Uses . . . . . . . . . . . . . . . . . . . . . . . 20
  4.7.  Environmental Concerns . . . . . . . . . . . . . . . . . . 20
  4.8.  Security Considerations  . . . . . . . . . . . . . . . . . 20
5.  Operational and Management Considerations  . . . . . . . . . . 20
  5.1.  Deployment of the CL Edge Behavior . . . . . . . . . . . . 20
    5.1.1.  Selection of Deployment Options and Global
            Parameters . . . . . . . . . . . . . . . . . . . . . . 20
    5.1.2.  Specification of Node- and Link-Specific Parameters  . 22
    5.1.3.  Installation of Parameters and Policies  . . . . . . . 23
    5.1.4.  Activation and Verification of All Behaviors . . . . . 24
  5.2.  Management Considerations  . . . . . . . . . . . . . . . . 25
    5.2.1.  Event Logging in the PCN-Domain  . . . . . . . . . . . 25
      5.2.1.1.  Logging Loss and Restoration of Contact  . . . . . 25
      5.2.1.2.  Logging Flow Termination Events  . . . . . . . . . 27
    5.2.2.  Provision and Use of Counters  . . . . . . . . . . . . 28
6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
  9.1.  Normative References . . . . . . . . . . . . . . . . . . . 31
  9.2.  Informative References . . . . . . . . . . . . . . . . . . 32

1. Introduction ✨

okay the whole point of PCN is to protect the quality of service (QoS) of inelastic flows inside a Diffserv domain, and it's supposed to do it in a simple, scalable, and robust way 🔥 It uses two mechanisms. The first is admission control, which decides whether to admit or block a new flow request. The second is flow termination, which only kicks in during abnormal circumstances and decides whether to terminate some of the flows that already exist 💅

To make this work, the overall rate of PCN-traffic gets metered on every link in the PCN-domain, and PCN-packets get marked when certain configured rates are exceeded. Those configured rates sit below the link's actual rate, so PCN-boundary-nodes get an early heads-up about incipient overloads before any congestion actually happens. That's where the "pre" part of "pre-congestion notification" comes from 🦋 The level of marking is what lets the network decide whether to admit or terminate PCN-flows. For more details, see [RFC5559] 💜

This document describes an experimental edge-node behavior for implementing PCN in a network. The experiment could be run in a network where a big chunk of the traffic is inelastic flows and where admission control of micro-flows is applied at the edge 🌈 For PCN's effects to be observable, the committed bandwidth (aka the level of non-best-effort traffic) on at least some links of the network should be near or at link capacity. Fair warning: the work needed to prep the network for the experiment (see Section 5.1) may limit how big a network can be used for it 😭 The purposes of the experiment are:

  • to validate the specification of the CL edge behavior;
  • to evaluate how effective the CL edge behavior is at preserving quality of service for admitted flows; and
  • to evaluate PCN's potential for reducing capital and operational costs compared to other ways of assuring quality of service.

For the first two objectives, the experiment should run long enough for the network to see sharp peaks of traffic in at least some directions. It would also be nice to observe PCN performance when the network has failures ⚡ A period on the order of a month or two in busy season may be enough. The third objective is trickier and could need observation over a long enough period for traffic demand to grow to the point where extra capacity has to be provisioned at some spots in the network 👑

Section 3 of this document specifies a detailed set of algorithms and procedures used to implement the PCN mechanisms for the CL mode of operation 🧠 Since those algorithms depend on specific metering and marking behavior at the interior nodes, the assumptions made about PCN-interior-node behavior also need to be specified (Section 2). Finally, PCN uses Diffserv codepoint (DSCP) values to carry its markings, so a specification of PCN-boundary-node behavior has to include the per-domain behavior (PDB) template specified in [RFC3086], filled out with the right content (Section 4) 🎀

Quick note: the terms "block" or "terminate" actually translate to one or more possible courses of action, as discussed in Section 3.6 of [RFC5559]. Which action to take for blocked or terminated flows is a matter of local policy 🍓

Lastly, a companion doc, [RFC6662], specifies the Single Marking (SM) PCN-boundary-node behavior. This document and [RFC6662] have a lot of text in common, so to make life easier for you, any text in this document that's specific to the CL PCN-boundary-node behavior is preceded by the phrase "[CL-specific]". A similar distinction for SM-specific text is made in [RFC6662] 🫶

1.1. Terminology

okay so bestie, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are interpreted as described in [RFC2119] 💅🎀. read those carefully, they're the rules with the real weight ✨

this doc borrows a bunch of terms from Section 2 of [RFC5559] 🦋:

  • PCN-domain
  • PCN-ingress-node
  • PCN-egress-node
  • PCN-interior-node
  • PCN-boundary-node
  • PCN-flow
  • ingress-egress-aggregate
  • [CL-specific] PCN-threshold-rate
  • PCN-excess-rate
  • PCN-admissible-rate
  • PCN-supportable-rate
  • PCN-marked
  • [CL-specific] threshold-marked
  • excess-traffic-marked

it also uses PCN-traffic and PCN-packet, and the definition is repeated from [RFC5559] because these matter so much for everything after 🧚 here's the lowdown:

PCN-traffic, PCN-packets, PCN-BA a PCN-domain carries traffic from different Diffserv behavior aggregates (BAs) [RFC2474] 🌸. the PCN-BA uses the PCN mechanisms to carry PCN-traffic, and the matching packets are PCN-packets. the same network will also carry traffic from other Diffserv BAs. the PCN-BA is identified by a combination of the Diffserv codepoint and the ECN field 💜

this doc also uses these terms from [RFC5670]:

  • [CL-specific] threshold-meter
  • excess-traffic-meter

to finish off the borrowed terms, the doc reuses these terms and abbreviations from Section 2 of [RFC6660] 💖:

  • not-PCN codepoint
  • not-marked (NM) codepoint
  • [CL-specific] threshold-marked (ThM) codepoint
  • excess-traffic-marked (ETM) codepoint

and then there are the new terms this document defines itself 👑

Decision Point the node that decides which flows get admitted and which get terminated 🔥. depending on the deployment, this can be the PCN-ingress-node or a centralized control node. either way, the PCN-ingress-node is where the decisions actually get enforced ✨

NM-rate the rate of not-marked PCN-traffic received at a PCN-egress-node for a given ingress-egress-aggregate, in octets per second 🦋. for more details, see Section 3.2.1.

[CL-specific] ThM-rate the rate of threshold-marked PCN-traffic received at a PCN-egress-node for a given ingress-egress-aggregate, in octets per second 🌈. for more details, see Section 3.2.1.

ETM-rate the rate of excess-traffic-marked PCN-traffic received at a PCN-egress-node for a given ingress-egress-aggregate, in octets per second 💅. for more details, see Section 3.2.1.

PCN-sent-rate the rate of PCN-traffic received at a PCN-ingress-node that is destined for a given ingress-egress-aggregate, in octets per second 🎀. for more details, see Section 3.4.

Congestion level estimate (CLE) the ratio of PCN-marked to total PCN-traffic (measured in octets) received for a given ingress-egress-aggregate during a given measurement period 📊. the CLE is used to derive the PCN-admission-state (Section 3.3.1), and it's also used by the report suppression procedure (Section 3.2.3) when report suppression is turned on 🫶.

PCN-admission-state the state ("admit" or "block") that the Decision Point derives for a given ingress-egress-aggregate, based on statistics about PCN-packet marking 🌸. the Decision Point admits or blocks new flows offered to the aggregate based on the current PCN-admission-state. for more details, see Section 3.3.1.

Sustainable aggregate rate (SAR) the estimated maximum rate of PCN-traffic that can be carried in a given ingress-egress-aggregate at a given moment without risking degradation of quality of service for the admitted flows 🧚. the idea is that if the PCN-sent-rate of every ingress-egress-aggregate passing through a given link is limited to its sustainable aggregate rate, then the total rate of PCN-traffic flowing through that link stays limited to the PCN-supportable-rate for that link 🔥. an estimate of the SAR for a given ingress-egress-aggregate is derived as part of the flow termination procedure, and it's used to figure out how much PCN-traffic needs to be terminated. for more details, see Section 3.3.2.

CLE-reporting-threshold a configurable value that the CLE gets compared against as part of the report suppression procedure 🍓. for more details, see Section 3.2.3.

CLE-limit a configurable value that the CLE gets compared against to determine the PCN-admission-state for a given ingress-egress-aggregate 💜. for more details, see Section 3.3.1.

T_meas a configurable time interval that defines the measurement period over which the PCN-egress-node collects statistics about PCN-traffic marking 🦋. at the end of the interval, the PCN-egress-node calculates NM-rate, [CL-specific] ThM-rate, and ETM-rate as defined above and sends a report to the Decision Point, subject to the report suppression feature 🌈. for more details, see Section 3.2.

T_maxsuppress a configurable time interval after which the PCN-egress-node MUST send a report to the Decision Point for a given ingress-egress-aggregate, no matter what the most recent CLE values were 🚨. this gives the Decision Point a periodic confirmation that the node is still alive when report suppression is activated 💖. for more details, see Section 3.2.3.

T_fail an interval after which the Decision Point concludes that communication from a given PCN-egress-node has failed, if it hasn't received any reports from that node during the interval 💀. for more details, see Section 3.3.3.

T_crit a configurable interval used in the calculation of T_fail 🙈. for more details, see Section 3.3.3.

2. [CL-Specific] Assumed Core Network Behavior for CL ✨

this section describes the behavior that's assumed for PCN-interior-nodes in the PCN-domain 🌸. the CL mode of operation assumes that:

  • PCN-interior-nodes perform both threshold-marking and excess-traffic-marking of PCN-packets, following the rules in [RFC5670] 💅;
  • for IP transport, threshold-marking of PCN-packets uses the ThM codepoint defined in [RFC6660]; for MPLS transport, an equivalent marking is used, as discussed in Appendix C of [RFC6660] 🎀;
  • for IP transport, excess-traffic-marking of PCN-packets uses the ETM codepoint defined in [RFC6660]; for MPLS transport, an equivalent marking is used, as discussed in Appendix C of [RFC6660] 🦋;
  • on each link, the reference rate for the threshold-meter is configured to be equal to the PCN-admissible-rate for the link 🌈;
  • on each link, the reference rate for the excess-traffic-meter is configured to be equal to the PCN-supportable-rate for the link 💜;
  • the set of valid codepoint transitions is as shown in Sections 5.2.1 and 5.2.2 of [RFC6660] 🫶.

3. Node Behaviors 🧚

3.1. Overview

this section describes the behavior of the PCN-ingress-node, the PCN-egress-node, and the Decision Point (which MAY be collocated with the PCN-ingress-node) 💖.

the PCN-egress-node collects the rates of not-marked, [CL-specific] threshold-marked, and excess-traffic-marked PCN-traffic for each ingress-egress-aggregate and reports them to the Decision Point 📊. [CL-specific] it MAY also identify and report PCN-flows that have experienced excess-traffic-marking 👑. for a detailed description, see Section 3.2.

the PCN-ingress-node enforces flow admission and termination decisions 🔥. it also reports the rate of PCN-traffic sent to a given ingress-egress-aggregate when the Decision Point asks for it 🌸. for details, see Section 3.4.

finally, the Decision Point makes flow admission decisions and selects flows to terminate, based on the information provided by the PCN-ingress-node and PCN-egress-node for a given ingress-egress-aggregate 🦋. for details, see Section 3.3.

specifying a signaling protocol to report rates to the Decision Point is out of scope for this document 🙅‍♀️. if the PCN-ingress-node is chosen as the Decision Point, [RSVP-PCN] specifies an appropriate signaling protocol 🎀.

Section 5.1.2 describes how to derive the filters that let PCN-ingress-nodes and PCN-egress-nodes classify incoming packets into ingress-egress-aggregates 🌈.

3.2. Behavior of the PCN-Egress-Node

3.2.1. Data Collection

the PCN-egress-node needs to meter the PCN-traffic it receives so it can calculate the following rates for each ingress-egress-aggregate passing through it 🧮. these rates SHOULD be calculated at the end of each measurement period, based on the PCN-traffic observed during that measurement period 💅. the duration of a measurement period is equal to the configurable value T_meas. for further information, see Section 3.5.

  • NM-rate: octets per second of PCN-traffic in PCN-packets that are not-marked (i.e., marked with the NM codepoint) 🌸;
  • [CL-specific] ThM-rate: octets per second of PCN-traffic in PCN-packets that are threshold-marked (i.e., marked with the ThM codepoint) 💜;
  • ETM-rate: octets per second of PCN-traffic in PCN-packets that are excess-traffic-marked (i.e., marked with the ETM codepoint) 🦋.
Note: metering the PCN-traffic continuously and using equal-length measurement intervals keeps the statistical variance from the measurement process itself to a minimum 📉. on the other hand, PCN still works fine if the starting and ending times of the measurement intervals differ between ingress-egress-aggregates 🫶.

[CL-specific] as a configurable option, the PCN-egress-node MAY record the flow identifiers of the PCN-flows for which excess-traffic-marked packets were observed during this measurement interval 🔍. if that set is large (e.g., more than 20 flows), the PCN-egress-node MAY record only the most recently excess-traffic-marked PCN-flow identifiers instead of the complete set 🍓.

these can be used by the Decision Point when it selects flows for termination ✨. in networks using multipath routing, it's possible that congestion isn't happening on every path carrying a given ingress-egress-aggregate 🛤️. assuming specific PCN-flows are routed via specific paths, identifying the PCN-flows that are experiencing excess-traffic-marking helps avoid terminating PCN-flows that aren't contributing to congestion 👑.

3.2.2. Reporting the PCN Data

unless the report suppression option described in Section 3.2.3 is activated, the PCN-egress-node MUST report the latest values of NM-rate, [CL-specific] ThM-rate, and ETM-rate to the Decision Point each time it calculates them 📣.

[CL-specific] if the PCN-egress-node recorded a set of flow identifiers of PCN-flows for which excess-traffic-marking was observed in the most recent measurement interval, then it MUST also include these identifiers in the report 🌈.

3.2.3. Optional Report Suppression 🔥

Okay so report suppression is a whole optional feature, bestie 💅 Report suppression MUST be provided as a configurable option, and it comes with two knobs: the CLE-reporting-threshold and the maximum report suppression interval T_maxsuppress. The CLE-reporting-threshold defaults to zero 🎀. It MUST NOT exceed the CLE-limit configured at the Decision Point. For more on T_maxsuppress, see Section 3.5 ✨.

If report suppression is turned on, the PCN-egress-node MUST follow this procedure to decide whether to send a report to the Decision Point. It does NOT just send one automatically at the end of every measurement interval, which is the whole point 🦋

  1. As well as the quantities NM-rate, [CL-specific] ThM-rate, and ETM-rate, the PCN-egress-node MUST calculate the congestion level estimate (CLE) for each measurement interval. The CLE is computed as:
[CL-specific]
CLE = (ThM-rate + ETM-rate) / (NM-rate + ThM-rate + ETM-rate)

if any PCN-traffic was observed, or CLE = 0 if all the rates are zero.

  1. If the CLE calculated for the latest measurement interval is greater than the CLE-reporting-threshold and/or the CLE calculated for the immediately previous interval was greater than the CLE-reporting-threshold, then the PCN-egress-node MUST send a report to the Decision Point. The contents of the report are described below.
Why do we look back at the previous interval too? Because the Decision Point needs to know right away if the CLE has dropped below CLE-reporting-threshold 🙈 This matters a LOT if the Decision Point is running the flow termination procedure and checking whether more flow termination is needed. See Section 3.3.2.
  1. If an interval T_maxsuppress has elapsed since the last report was sent to the Decision Point, then the PCN-egress-node MUST send a report to the Decision Point regardless of the CLE value.
  2. If neither of the preceding conditions holds, the PCN-egress-node MUST NOT send a report for the latest measurement interval.

Each report sent to the Decision Point when report suppression has been activated MUST contain the values of NM-rate, [CL-specific] ThM-rate, ETM-rate, and CLE that were calculated for the most recent measurement interval. [CL-specific] If the PCN-egress-node recorded a set of flow identifiers of PCN-flows for which excess-traffic-marking was observed in the most recent measurement interval, then it MUST also include these identifiers in the report 🧚

This whole procedure guarantees that at least one report goes out per interval (T_maxsuppress + T_meas). That's how the Decision Point knows both the PCN-egress-node and the communication path between them are still alive and well 🫶

3.3. Behavior at the Decision Point 👑

Operators get to pick: PCN procedures can be used just for flow admission, just for flow termination, or for both 💜 Decision Points MUST implement both mechanisms, but configurable options MUST be provided to turn PCN-based flow admission and flow termination on or off independently of each other at a given Decision Point.

If PCN-based flow termination is enabled but PCN-based flow admission is not, then flow termination works exactly as specified in this document 🌸

Logically, some other system of flow admission control is in operation, but the description of such a system is out of scope of this document and depends on local arrangements.

3.3.1. Flow Admission 🍓

The Decision Point works out the PCN-admission-state for a given ingress-egress-aggregate every single time it gets a report from the egress node 💅 It bases this on the congestion level estimate (CLE). If the CLE is provided in the egress-node report, the Decision Point SHOULD use that reported value. If the CLE was NOT included in the report, the Decision Point MUST calculate it from the other values in the report, using this formula:

[CL-specific]
CLE = (ThM-rate + ETM-rate) / (NM-rate + ThM-rate + ETM-rate)

if any PCN-traffic was observed, or CLE = 0 if all the rates are zero.

The Decision Point MUST compare the reported or calculated CLE to a configurable value called the CLE-limit. If the CLE is less than the CLE-limit, the PCN-admission-state for that aggregate MUST be set to "admit"; otherwise, it MUST be set to "block" 🚦

If the PCN-admission-state for a given ingress-egress-aggregate is "admit", the Decision Point SHOULD allow new flows to be admitted to that aggregate. If the PCN-admission-state is "block", the Decision Point SHOULD NOT allow new flows into that aggregate. Policy MAY modify these actions in specific cases, but that kind of policy intervention risks defeating the purpose of using PCN 🙈

A performance study of this admission control method is presented in [MeLe12] 📚

3.3.2. Flow Termination ✨

[CL-specific] When the report from the PCN-egress-node includes a non-zero value of the ETM-rate for some ingress-egress-aggregate, the Decision Point MUST request the PCN-ingress-node to provide an estimate of the rate (PCN-sent-rate) at which the PCN-ingress-node is receiving PCN-traffic destined for that ingress-egress-aggregate.

If the Decision Point is collocated with the PCN-ingress-node, the request and response are internal operations.

The Decision Point MUST then wait for both the requested rate from the PCN-ingress-node and the next report from the PCN-egress-node for the ingress-egress-aggregate concerned. If this next egress-node report ALSO includes a non-zero value for the ETM-rate, the Decision Point MUST determine how much PCN-traffic to terminate using these steps:

  1. [CL-specific] The sustainable aggregate rate (SAR) for the given ingress-egress-aggregate is estimated by the sum:
SAR = NM-rate + ThM-rate

for the latest reported interval.

  1. The amount of traffic to be terminated is the difference:
PCN-sent-rate - SAR,

where PCN-sent-rate is the value provided by the PCN-ingress-node.

See Section 3.3.3 for a discussion of appropriate actions if the Decision Point fails to receive a timely response to its request for the PCN-sent-rate 🫣

If the difference calculated in the second step is positive (the traffic rate to be terminated), the Decision Point SHOULD select PCN-flows for termination. To do that, the Decision Point MAY use upper rate limits for individual PCN-flows (known, e.g., from resource signaling used to establish the PCN-flows) and select a set of PCN-flows whose sum of upper rate limits is up to the traffic rate to be terminated. Then those PCN-flows get terminated. Using upper limits on PCN-flow rates avoids over-termination 🎯

Termination might be needed continuously after consecutive measurement intervals for various reasons, e.g., if the upper rate limits being used overestimate the actual flow rates. For such cases, it is RECOMMENDED that enough time elapses between successive termination events so that the effects of previous termination events can show up in the measurements the termination decisions are based on. Otherwise, over-termination may occur 😭 See [Satoh10] and Sections 4.2 and 4.3 of [MeLe10].

In general, selecting flows for termination MAY be guided by policy. [CL-specific] If the egress node has supplied a list of identifiers of PCN-flows that experienced excess-traffic-marking (Section 3.2), the Decision Point SHOULD first consider terminating the PCN-flows on that list 🌈

The Decision Point SHOULD log each round of termination as described in Section 5.2.1.2 📝

3.3.3. Decision Point Action for Missing PCN-Boundary-Node Reports 🚨

The Decision Point SHOULD start a timer, t_recvFail, when it receives a report from the PCN-egress-node. t_recvFail gets reset every time a new report comes in from the PCN-egress-node. t_recvFail expires if it reaches the value T_fail. T_fail is calculated like this:

  • a. T_fail = the configurable duration T_crit, if report suppression is not deployed;
  • b. T_fail = T_crit also if report suppression is deployed and the last report received from the PCN-egress-node contained a CLE value greater than CLE-reporting-threshold (Section 3.2.3);
  • c. T_fail = 3 * T_maxsuppress (Section 3.2.3) if report suppression is deployed and the last report received from the PCN-egress-node contained a CLE value less than or equal to CLE-reporting-threshold.

If timer t_recvFail expires for a given PCN-egress-node, the Decision Point SHOULD notify management. A log format is defined for that purpose in Section 5.2.1.1. Other actions depend on local policy, but MAY include blocking new flows destined for the PCN-egress-node concerned until another report is received from it. Terminating already admitted flows is also possible, but it could be triggered by "Destination unreachable" messages received at the PCN-ingress-node 🧯

If a centralized Decision Point sends a request for the estimated value of PCN-sent-rate to a given PCN-ingress-node and doesn't get a response in a reasonable amount of time, the Decision Point SHOULD repeat the request once. [CL-specific] While it waits after sending this second request, the Decision Point MAY begin selecting flows to terminate, using ETM-rate as an estimate of how much traffic needs terminating in place of the quantity from Section 3.3.2:

PCN-sent-rate - SAR

ETM-rate will over-estimate the amount of traffic to be terminated because interior nodes drop some PCN-packets. So the Decision Point SHOULD terminate LESS than the full ETM-rate amount in the first pass, then recalculate the extra amount to terminate in later passes based on subsequent reports from the PCN-egress-node. If the second request to the PCN-ingress-node also fails, the Decision Point MUST select flows to terminate based on the ETM-rate approximation just described, and SHOULD notify management. The log format described in Section 5.2.1.1 is also suitable for this purpose 🌷

The response timer t_sndFail with upper bound T_crit is specified in Section 3.5. Using T_crit is an approximation. A more precise limit would be on the order of two round-trip times, plus an allowance for processing at each end, plus an allowance for variance in these values.

See Section 3.5 for suggested values of the configurable durations T_crit and T_maxsuppress 💖

3.4. Behavior of the Ingress Node 🧚‍♀️

The PCN-ingress-node MUST provide the estimated current rate of PCN-traffic it receives that is destined for a given ingress-egress-aggregate, in octets per second (the PCN-sent-rate), whenever the Decision Point requests it. How that rate estimate gets derived is up to the implementation 🌸

For example, the rate that the PCN-ingress-node supplies can be based on a quick sample taken at the time the information is required.

3.5. Summary of Timers and Associated Configurable Durations ⏰

okay so here's the cheat sheet for all the timers in the procedures we just went through, bestie 💖

  • t_meas 📏
    • Where used: PCN-egress-node.
    • Used in procedure: data collection (Section 3.2.1).
    • Incidence: one per ingress-egress-aggregate.
    • Reset: immediately on expiry.
    • Expiry: when it reaches the configurable duration T_meas.
    • Action on expiry: calculate NM-rate, [CL-specific] ThM-rate, and ETM-rate and proceed to the applicable reporting procedure (Section 3.2.2 or Section 3.2.3).
  • t_maxsuppress 🤫
    • Where used: PCN-egress-node.
    • Used in procedure: report suppression (Section 3.2.3).
    • Incidence: one per ingress-egress-aggregate.
    • Reset: when the next report is sent, either after expiry or because the CLE has exceeded the reporting threshold.
    • Expiry: when it reaches the configurable duration T_maxsuppress.
    • Action on expiry: send a report to the Decision Point the next time the reporting procedure (Section 3.2.3) is invoked, regardless of the value of CLE.
  • t_recvFail 📭
    • Where used: Decision Point.
    • Used in procedure: failure detection (Section 3.3.3).
    • Incidence: one per ingress-egress-aggregate.
    • Reset: when a report is received for the ingress-egress-aggregate.
    • Expiry: when it reaches the calculated duration T_fail. As described in Section 3.3.3, T_fail is equal either to the configured duration T_crit or to the calculated value 3 * T_maxsuppress, where T_maxsuppress is a configured duration.
    • Action on expiry: notify management, and possibly other actions.
  • t_sndFail 📤
    • Where used: centralized Decision Point.
    • Used in procedure: failure detection (Section 3.3.3).
    • Incidence: only as required, one per outstanding request to a PCN-ingress-node.
    • Started: when a request for the value of PCN-sent-traffic for a given ingress-egress-aggregate is sent to the PCN-ingress-node.
    • Terminated without action: when a response is received before expiry.
    • Expiry: when it reaches the configured duration T_crit.
    • Action on expiry: as described in Section 3.3.3.

the timers we just covered depend on three configurable durations: T_meas, T_maxsuppress, and T_crit 💅. all the recommendations below are tied to the intended PCN reaction time of 1 to 3 seconds ⏱️. BUT, and this is important, they're based on judgement rather than operational experience or mathematical derivation, so don't treat them as gospel 🙈

the value of T_meas is RECOMMENDED to be on the order of 100 to 500 ms 🍃. this gives a reasonable trade-off between demands on network resources (PCN-egress-node and Decision Point processing, network bandwidth) and how fast the network can react to impending congestion ✨

the value of T_maxsuppress is RECOMMENDED to be on the order of 3 to 6 seconds, for similar reasons to the ones behind the choice of T_meas 💜

the value of T_crit SHOULD NOT be less than 3 * T_meas. otherwise it could cause too many management notifications due to transient conditions in the PCN-egress-node or along the signaling path 😭. a reasonable upper bound on T_crit is on the order of 3 seconds 🍑

4. Specification of Diffserv Per-Domain Behavior 🎀

this section provides the specification required by [RFC3086] for a per-domain behavior. it's the official paperwork, babe 📜

4.1. Applicability 🧭

this section quotes [RFC5559].

the PCN CL boundary node behavior specified in this document is applicable to inelastic traffic (particularly video and voice) where quality of service for admitted flows is protected primarily by admission control at the ingress to the domain 📞🎥. the vibe is: keep the calls and streams clean from the front door 🚪

in exceptional circumstances (e.g., due to rerouting as a result of network failures), already admitted flows may be terminated to protect the quality of service of the remaining flows 😬. [CL-specific] the performance results in, e.g., [MeLe10], indicate that the CL boundary node behavior provides better service outcomes under such circumstances than the SM boundary node behavior described in [RFC6662], because CL is less likely to terminate PCN-flows unnecessarily 👑. literally the main character move 💅

4.2. Technical Specification 🛠️

4.2.1. Classification and Traffic Conditioning 🔍

packet classification and treatment at the PCN-ingress-node is described in Section 5.1 of [RFC6660] 🗂️.

PCN packets are further classified as belonging or not belonging to an admitted flow. PCN packets not belonging to an admitted flow are "blocked" 🚫. (See Section 1 for an understanding of how this term is interpreted.) packets belonging to an admitted flow are policed to make sure they stick to the rate or flowspec that was negotiated during flow admission 🤝. no cheating allowed 🙅‍♀️

4.2.2. PHB Configuration ⚙️

the PCN CL boundary node behavior is a metering and marking behavior rather than a scheduling behavior 🎨. as a result, while the encoding uses a single DSCP value, that value can vary from one deployment to another 🦋. the PCN working group suggests using admission control for the following service classes (defined in [RFC4594]):

  • Telephony (EF) 📱
  • Real-time interactive (CS4) 🗣️
  • Broadcast Video (CS3) 📺
  • Multimedia Conferencing (AF4) 🎥

for a fuller discussion, see Appendix A of [RFC6660] 📖.

4.3. Attributes 🌟

the purpose of this per-domain behavior is to achieve low loss and jitter for the target class of traffic 🫧. the design requirement for PCN was that recovery from overloads through the use of flow termination should happen within 1-3 seconds ⚡. PCN probably performs better than that, ngl 😤

4.4. Parameters 🧮

the set of parameters that needs to be configured at each PCN-node and at the Decision Point is described in Section 5.1 📋.

4.5. Assumptions 🤔

it is assumed that a specific portion of link capacity has been reserved for PCN-traffic 🧃.

4.6. Example Uses 🌈

the PCN CL behavior may be used to carry real-time traffic, particularly voice and video 📹🎙️.

4.7. Environmental Concerns 🌍

the PCN CL per-domain behavior could theoretically interfere with the use of end-to-end ECN due to reuse of ECN bits for PCN marking 🧐. Section 5.1 of [RFC6660] describes the actions that can be taken to protect ECN signaling 🛡️. Appendix B of that document provides further discussion of how ECN and PCN can coexist 🤝.

4.8. Security Considerations 🔐

⚠️ please see the security considerations in [RFC5559] as well as those in [RFC2474] and [RFC2475]. these are not optional reading, bestie 💀

5. Operational and Management Considerations 🧑‍💻

5.1. Deployment of the CL Edge Behavior 🚀

deployment of the PCN Controlled Load edge behavior requires the following steps:

  • selection of deployment options and global parameter values;
  • derivation of per-node and per-link information;
  • installation, but not activation, of parameters and policies at all of the nodes in the PCN-domain;
  • activation and verification of all behaviors.

5.1.1. Selection of Deployment Options and Global Parameters 🎛️

the first set of decisions affects the operation of the network as a whole 🌐. to begin with, the operator needs to make basic design decisions such as whether the Decision Point is centralized or collocated with the PCN-ingress-nodes, and whether per-flow and aggregate resource signaling as described in [RSVP-PCN] is deployed in the network 🧠. after that, the operator needs to decide:

  • whether PCN packets will be forwarded unencapsulated or in tunnels between the PCN-ingress-node and the PCN-egress-node. encapsulation preserves incoming ECN settings and simplifies the PCN-egress-node's job when it comes to relating incoming packets to specific ingress-egress-aggregates, but it lowers the path MTU and imposes the extra labor of encapsulation/decapsulation on the PCN-edge-nodes 📦😵.
  • which service classes will be subject to PCN control and what DSCP will be used for each. (See [RFC6660] Appendix A for advice on this topic.) 🏷️
  • the markings to be used at all nodes in the PCN-domain to indicate not-marked (NM), [CL-specific] threshold-marked (ThM), and excess-traffic-marked (ETM) PCN packets 🎨.
  • the marking rules for re-marking PCN-traffic leaving the PCN-domain 🔁.
  • whether PCN-based flow admission is enabled 🚪.
  • whether PCN-based flow termination is enabled 🛑.

the following parameters affect the operation of PCN itself. the operator needs to choose:

  • the value of CLE-limit if PCN-based flow admission is enabled. [CL-specific] in practice, the operation of flow admission is not very sensitive to the value of the CLE-limit, because when threshold-marking occurs it tends to persist long enough that threshold-marked traffic becomes a large proportion of the received traffic in a given interval 🧁.
  • the value of the collection interval T_meas. for a recommended range of values, see Section 3.5.1 above ⏲️.
  • whether report suppression is to be enabled at the PCN-egress-nodes and, if so, the values of CLE-reporting-threshold and T_maxsuppress. it is reasonable to leave CLE-reporting-threshold at its default value (zero, as specified in Section 3.2.3). for a recommended range of values of T_maxsuppress, see Section 3.5.1 above 🤫.
  • the value of the duration T_crit, which the Decision Point uses in deciding whether communications with a given PCN-edge-node have failed. for a recommended range of values of T_crit, see Section 3.5.1 above 📡.
  • [CL-specific] activation/deactivation of recording of individual flow identifiers when excess-traffic-marked PCN-traffic is observed. reporting these identifiers has value only if PCN-based flow termination is activated and Equal Cost Multi-Path (ECMP) routing is enabled in the PCN-domain 🔍🦋.

okay bestie, filters are required at both the PCN-ingress-node and the PCN-egress-node so they can sort incoming PCN packets by ingress-egress-aggregate 🎀. Here's the tea: if there's multipath routing upstream of the PCN-domain, the PCN-egress-node can't reliably sort packets by their header contents as they first arrived at the PCN-ingress-node. Packets with identical headers can walk into the PCN-domain through different PCN-ingress-nodes 😭. So the only reliable way to build those filters is to tunnel the packets from the PCN-ingress-node to the PCN-egress-node 🦋.

The PCN-ingress-node needs its filters for two jobs: putting PCN packets into the right tunnel in the first place, and answering the Decision Point when it asks for admission rates into specific ingress-egress-aggregates 💅. These filters pick out the PCN-egress-node, not one exact path to it, so they stay pretty stable even when the network has failures. The exception is when the PCN-egress-node itself becomes unreachable 💀. If every PCN packet gets tunneled, the PCN-ingress-node also needs to know the address of the peer PCN-egress-node for each filter 🫶.

Operators might want to think about setting up alternate egress points for some or all ingress-egress-aggregates, in case the PCN-egress-node goes down 🌸. That could mean setting up standby tunnels to those alternate egress points. Very prepared, very iconic ✨.

Each PCN-egress-node also needs filters to sort incoming PCN packets by ingress-egress-aggregate, so it can gather measurements per aggregate 📊. If tunneling is in use, those filters are built from the identifier of the tunnel the packet came out of (for example, the source address in the outer header when IP encapsulation is used) 🧚. The PCN-egress-node also needs the address of the Decision Point it sends reports to for each ingress-egress-aggregate 💜.

A centralized Decision Point needs the address of the PCN-ingress-node for each ingress-egress-aggregate 🍓. Security considerations also require that this information is prepared for a centralized Decision Point and each PCN-edge-node, so they can authenticate each other 🔐. No skipping that part, babe.

Now for the link-specific parameters 🌈. The operator needs to derive values for the PCN-admissible-rate and [CL-specific] PCN-supportable-rate on each link in the network. The first two paragraphs of Section 5.2.2 of [RFC5559] explain how those values can be derived 📚.

5.1.3. Installation of Parameters and Policies 🎀

okay so, as we talked about in the last two sections, every PCN node needs to be provisioned with a bunch of parameters and policies about how it handles incoming packets 💖. The Diffserv MIB [RFC3289] can be super useful for this, although it needs extending in some cases 🛠️. This MIB covers packet classification, metering, counting, policing, dropping, and marking. The required extensions specifically include an encapsulation action that follows reclassification by ingress-egress-aggregate 🦋. The MIB also has to be extended with objects for marking the ECN field in the outer header at the PCN-ingress-node, and with an extension to the classifiers so they can look at the ECN field at PCN-interior and PCN-egress-nodes 💅. Finally, new objects may need to be defined at the PCN-interior-nodes to represent the metering algorithms for threshold-marking and packet-size-independent excess-traffic-marking 🌸.

The values for the PCN-admissible-rate and [CL-specific] PCN-supportable-rate on each link of a node show up as metering parameters 📏. Operators should keep in mind that they need to deploy meters of a given type (threshold or excess-traffic) either on the ingress or the egress side of each interior link, but not both (Appendix B.2 of [RFC5670].) 🙈

The following extra information has to be configured by other means, like additional MIBs or NETCONF models ⭐.

At the PCN-egress-node:

  • the measurement interval T_meas (units of ms, range 50 to 1000); 📊
  • [CL-specific] whether specific flow identifiers must be captured when excess-traffic-marked packets are observed; 🔍
  • whether report suppression is to be applied; 🙅‍♀️
  • if so, the interval T_maxsuppress (units of 100 ms, range 1 to 100) and the CLE-reporting-threshold (units of tenths of one percent, range 0 to 1000, default value 0); 💜
  • the address of the PCN-ingress-node for each ingress-egress-aggregate, if the Decision Point is collocated with the PCN-ingress-node and [RSVP-PCN] is not deployed; 🧚
  • the address of the centralized Decision Point to which it sends its reports, if there is one. 💌

At the Decision Point:

  • whether PCN-based flow admission is enabled; ✅
  • whether PCN-based flow termination is enabled; ❌
  • the value of CLE-limit (units of tenths of one percent, range 0 to 1000); 🔥
  • the value of the interval T_crit (units of 100 ms, range 1 to 100); ⏱️
  • whether report suppression is to be applied; 🙅‍♀️
  • if so, the interval T_maxsuppress (units of 100 ms, range 1 to 100) and the CLE-reporting-threshold (units of tenths of one percent, range 0 to 1000, default value 0). These MUST be the same values that are provisioned in the PCN-egress-nodes 🚨;
  • if the Decision Point is centralized, the address of the PCN-ingress-node (and any other information needed to establish a security association) for each ingress-egress-aggregate. 🔐

Depending on the testing strategy, it might be necessary to install the new configuration data in stages 🪜. We'll get into that more below 👀.

5.1.4. Activation and Verification of All Behaviors 🧪

real talk, this document is definitely NOT the place to tell you how to test, because operators have that totally handled 💅✨. Honestly, an operator might prefer rolling things out incrementally, and that makes total sense 🌷. Just putting the PCN marking scheme on PCN-ingress-nodes, the matching scheduling behavior in downstream nodes, and re-marking at the PCN-egress-nodes is already a big enough step to need thorough testing before going any further 😤.

Testing will probably mean injecting packets at individual nodes and tracking how each node handles them 🔬. That work can use the counter capabilities in the Diffserv MIB 📈. How those capabilities apply to managing PCN is covered in the next section, so keep scrolling, bestie 💖.

5.2. Management Considerations 🎀

this section is all about event logging and the counters the Diffserv MIB [RFC3289] supports, which are used for the different monitoring tasks in running a PCN network 🌈.

5.2.1. Event Logging in the PCN-Domain 📝

event logging with SYSLOG [RFC5424] is expected to be needed for fault management, and maybe for capacity management too 🦋. Implementations MUST be capable of generating logs for the following events:

  • detection of loss of contact between a Decision Point and a PCN-edge-node, as described in Section 3.3.3; 😱
  • successful receipt of a report from a PCN-egress-node, following detection of loss of contact with that node; 🥳
  • flow termination events. 🏁

All of these logs come from the Decision Point 👑. In the first and third cases there's a strong chance the events are linked to network failures at a lower level 🫣. That matters for how often each event type should get reported, so the log buffer doesn't overflow for no reason 🪣. Recommendations for each event report type come next ✨.

The field names used in the subsections below (like HOSTNAME and STRUCTURED-DATA) are defined in [RFC5424] 💜.

5.2.1.1. Logging Loss and Restoration of Contact 🔌

Section 3.3.3 explains when the Decision Point might decide it has lost contact with a PCN-ingress-node or a PCN-egress-node, because it didn't get an expected report 📭. Losing contact with a PCN-ingress-node is mainly a thing when the Decision Point lives on a separate node 🏠. However, implementations MAY implement logging in the collocated case, if the implementation can sometimes fail to respond to a request from the Decision Point function because of processor load or other reasons 🧠.

The log reporting loss of contact with a PCN-ingress-node or PCN-egress-node MUST include the following content:

  • The HOSTNAME field MUST identify the Decision Point issuing the log. 🖥️
  • A STRUCTURED-DATA element MUST be present, containing parameters that identify the node whose expected report hasn't arrived, plus the type of report lost (ingress or egress) 🧾. It is RECOMMENDED that the SD-ID for the STRUCTURED-DATA element have the form "PCNNode" (without the quotes), which has been registered with IANA 🪪. The node identifier PARAM-NAME is RECOMMENDED to be "ID" (without the quotes). The identifier itself is subject to the preferences in Section 6.2.4 of [RFC5424] for the HOSTNAME field 🎯. The report type PARAM-NAME is RECOMMENDED to be "RTyp" (without the quotes). The PARAM-VALUE for the RTyp field MUST be either "ingr" or "egr" (without the quotes) 💅.

The following values are also RECOMMENDED for the indicated fields in this log, subject to local practice 🌟:

  • PRI initially set to 115, representing a Facility value of (14) "log alert" and a Severity level of (3) "Error Condition" 🚨. Note that loss of contact with a PCN-egress-node implies that no new flows will be admitted to one or more ingress-egress-aggregates until contact is restored 🚫. The reason a higher severity level (lower value) isn't proposed for the initial log is that any corrective action would probably be based on alerts at a lower subsystem level 🔧.
  • APPNAME set to "PCN" (without the quotes). 🏷️
  • MSGID set to "LOST" (without the quotes). 🥀

If contact isn't regained with a PCN-egress-node within a reasonable period of time (say, one minute), the log SHOULD be repeated 🕐. This time it gets a PRI value of 113, implying a Facility value of (14) "log alert" and a Severity value of (1) "Alert: action must be taken immediately" 📣. The reasoning is that by now any more general conditions should have cleared, so the problem is specifically with that PCN-egress-node and the PCN application 🎯.

Whenever a loss-of-contact log is generated for a PCN-egress-node, a log indicating recovery SHOULD be generated the next time the Decision Point receives a report from that node 🎉. That log SHOULD have the same content as the loss-of-contact log described above, with these differences:

  • PRI changes to 117, indicating a Facility value of (14) "log alert" and a Severity of (5) "Notice: normal but significant condition" 🌤️
  • MSGID changes to "RECVD" (without the quotes). 💫

5.2.1.2. Logging Flow Termination Events 🩷

okay so Section 3.3.2 is where the Decision Point decides flow termination is needed for a given ingress-egress-aggregate, works out how much flow to kick out, and picks which flows go 💅. This section is about a log that SHOULD be generated every time that happens. (If termination happens in multiple rounds, one log SHOULD be generated per round 🔁.) It's super useful for fault management, since it shows the service impact of a fault in a lower-level subsystem 🛠️. And if there aren't any network failures, it can also be a sign that the capacity along the path of that ingress-egress-aggregate needs an urgent look 👀.

the log reporting a flow termination event MUST include the following content:

  • the HOSTNAME field MUST identify the Decision Point that issued the log 🫶.
  • a STRUCTURED-DATA element MUST be present. It has to contain parameters that identify the ingress and egress nodes for the ingress-egress-aggregate, show the total amount of flow being terminated, and give the number of flows that were terminated to hit that target ✨.

it is RECOMMENDED that the SD-ID for the STRUCTURED-DATA element looks like PCNTerm (no quotes), which is registered with IANA 🎀. the parameter for the ingress node is RECOMMENDED to use PARAM-NAME IngrID (no quotes). the parameter for the egress node is RECOMMENDED to use PARAM-NAME EgrID (no quotes). both identifiers are subject to the preferences in Section 6.2.4 of [RFC5424] for the HOSTNAME field 🧚.

the parameter giving the total amount of flow being terminated is RECOMMENDED to use PARAM-NAME TermRate (no quotes). its PARAM-VALUE MUST be the target rate calculated using the procedures in Section 3.3.2, written as an integer in thousands of octets per second 🍓. the parameter giving the number of flows selected for termination is RECOMMENDED to use PARAM-NAME FCnt (no quotes), and its PARAM-VALUE MUST be an integer, which is the number of flows selected 💜.

the following values are also RECOMMENDED for the listed fields in this log, subject to local practice 🌈:

  • PRI initially set to 116, which means a Facility value of (14) "log alert" and a Severity level of (4) "Warning: warning conditions" ⚠️.
  • APPNAME set to "PCN" (no quotes) 🦋.
  • MSGID set to "TERM" (no quotes) 💖.

5.2.2. Provision and Use of Counters 📊

the Diffserv MIB [RFC3289] lets you set up counters along the different possible processing paths tied to an interface and flow direction. it is RECOMMENDED that the PCN-nodes be instrumented the way described below 🌸. the assumption is that the cumulative counts you get will be collected periodically for debugging, fault management, and capacity management 🧁.

PCN-ingress-nodes SHOULD provide the following counts for each ingress-egress-aggregate. the Diffserv MIB installs counters per interface and direction, so you may need to add counts across several interfaces to get the totals for an ingress-egress-aggregate. that aggregation is expected to happen in a central system, not on the PCN-ingress-node 🏢.

  • total PCN packets and octets that were received for that ingress-egress-aggregate but were dropped 🗑️;
  • total PCN packets and octets admitted to that aggregate ✅.

PCN-interior-nodes SHOULD provide the following counts for each interface. a given packet MUST NOT be counted more than once as it passes through the node 🚫:

  • total PCN packets and octets dropped 💧;
  • total PCN packets and octets forwarded without re-marking 🏃‍♀️;
  • [CL-specific] total PCN packets and octets re-marked to threshold-marked 🟡;
  • total PCN packets and octets re-marked to excess-traffic-marked 🔴.

PCN-egress-nodes SHOULD provide the following counts for each ingress-egress-aggregate. just like the PCN-ingress-node, any aggregation across multiple interfaces is expected to be done by a central system 🧩.

  • total not-marked PCN packets and octets received 🩵;
  • [CL-specific] total threshold-marked PCN packets and octets received 💛;
  • total excess-traffic-marked PCN packets and octets received 🧡.

the following continuously cumulative counters SHOULD be provided as indicated, but they need new MIBs to be defined 🙈. if the Decision Point is not collocated with the PCN-ingress-node, the PCN-ingress-node SHOULD provide a count of the requests for PCN-sent-rate it received from the Decision Point, plus the number of responses it returned to the Decision Point. the PCN-egress-node SHOULD provide a count of the reports it sent to each Decision Point. and each Decision Point SHOULD provide the following 👑:

  • total number of requests for PCN-sent-rate sent to each PCN-ingress-node it is not collocated with 📤;
  • total number of reports received from each PCN-egress-node 📥;
  • total number of loss-of-contact events detected for each PCN-boundary-node 📉;
  • total cumulative duration of "block" state, in hundreds of milliseconds, for each ingress-egress-aggregate ⏱️;
  • total number of rounds of flow termination exercised for each ingress-egress-aggregate 🔁.

6. Security Considerations 🔐

[RFC5559] gives a general description of the security considerations for PCN. this memo adds one new consideration, which is about using a centralized Decision Point. the Decision Point itself is a trusted entity. however, using it implies there's an interface on the PCN-ingress-node where policy decisions get communicated. that interface is a point of vulnerability, and it must be protected from denial-of-service attacks 🚨. this one's serious, bestie, so please don't skip it 😭.

7. IANA Considerations 🧾

IANA has added the following entries to the "syslog Structured Data ID Values" registry 📋.

      Structured Data ID: PCNNode             OPTIONAL

         Structured Data Parameter: ID        MANDATORY

         Structured Data Parameter: Rtyp      MANDATORY

      Reference: RFC 6661

      Structured Data ID: PCNTerm             OPTIONAL

         Structured Data Parameter: IngrID    MANDATORY

         Structured Data Parameter: EgrID     MANDATORY

         Structured Data Parameter: TermRate  MANDATORY

         Structured Data Parameter: FCnt      MANDATORY

      Reference: RFC 6661

8. Acknowledgements 🫶

this memo has a family resemblance to [Briscoe-CL] 👯. the authors of that doc were Bob Briscoe, Philip Eardley, and Dave Songhurst of BT, Anna Charny and Francois Le Faucheur of Cisco, Jozef Babiarz, Kwok Ho Chan, and Stephen Dudley of Nortel, Giorgios Karagiannis of U. Twente and Ericsson, and Attila Bader and Lars Westberg of Ericsson 🌟.

Ruediger Geib, Philip Eardley, and Bob Briscoe helped shape this document with their comments 💬. Toby Moncaster gave a careful review to get it into shape for Working Group Last Call 🙌.

Michael Menth deserves a special shoutout among the authors for his constant, careful attention to both the technical content and how it was expressed 👑💜.

David Harrington's careful AD review led to necessary changes throughout the document, and also to the addition of the operations and management considerations (Section 5) 🎀.

as part of the broader review process, the document got further improvements from comments by Joel Halpern, Brian Carpenter, Stephen Farrell, Sean Turner, and Pete Resnick 🌷.

9. References 📚

9.1. Normative References

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

[RFC2474]     Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              December 1998.

[RFC2475]     Blake, S., Black, D., Carlson, M., Davies, E., Wang,
              Z., and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

[RFC3086]     Nichols, K. and B. Carpenter, "Definition of
              Differentiated Services Per Domain Behaviors and Rules
              for their Specification", RFC 3086, April 2001.

[RFC3289]     Baker, F., Chan, K., and A. Smith, "Management
              Information Base for the Differentiated Services
              Architecture", RFC 3289, May 2002.

[RFC5424]     Gerhards, R., "The Syslog Protocol", RFC 5424,
              March 2009.

[RFC5559]     Eardley, P., "Pre-Congestion Notification (PCN)
              Architecture", RFC 5559, June 2009.

[RFC5670]     Eardley, P., "Metering and Marking Behaviour of PCN-
              Nodes", RFC 5670, November 2009.

[RFC6660]     Briscoe, B., Moncaster, T., and M. Menth, "Encoding
              Three Pre-Congestion Notification (PCN) States in the
              IP Header Using a Single Diffserv Codepoint (DSCP)",
              RFC 6660, July 2012.

9.2. Informative References

[Briscoe-CL]  Briscoe, B., Eardley, P., Songhurst, D., Le Faucheur,
              F., Charny, A., Babiarz, J., Chan, K., Dudley, S.,
              Karagiannis, G., Bader, A., and L. Westberg, "An edge-
              to-edge Deployment Model for Pre-Congestion
              Notification: Admission Control over a DiffServ
              Region", Work in Progress, October 2006.

[MeLe10]      Menth, M. and F. Lehrieder, "PCN-Based Measured Rate
              Termination", Computer Networks Journal (Elsevier) vol.
              54, no. 13, pp. 2099-2116, September 2010.

[MeLe12]      Menth, M. and F. Lehrieder, "Performance of PCN-Based
              Admission Control under Challenging Conditions", IEEE/
              ACM Transactions on Networking, vol. 20, no. 2,
              April 2012.

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

[RFC6662]     Charny, A., Zhang, J., Karagiannis, G., Menth, M., and
              T. Taylor, Ed., "Pre-Congestion Notification (PCN)
              Boundary Node Behavior for the Single Marking (SM) Mode
              of Operation", RFC 6662, July 2012.

[RSVP-PCN]    Karagiannis, G. and A. Bhargava, "Generic Aggregation
              of Resource ReSerVation Protocol (RSVP) for IPv4 And
              IPv6 Reservations over PCN domains", Work in Progress,
              July 2012.

[Satoh10]     Satoh, D. and H. Ueno, "Cause and Countermeasure of
              Overtermination for PCN-Based Flow Termination",
              Proceedings of IEEE Symposium on Computers and
              Communications (ISCC '10), pp. 155-161,
              Riccione, Italy, June 2010.

Authors' Addresses ✨

okay bestie, these are the four humans who wrote this RFC, and yes I'm going to list their contact info like a fan club directory 💜🫶

Anna Charny is in the USA 🇺🇸. Her email is anna@mwsm.com 💌

Anna Charny
USA

EMail: anna@mwsm.com

Fortune Huang is at Huawei Technologies in Shenzhen, China 🇨🇳 🌸. Here's the full address and contact info, no cap:

Fortune Huang
Huawei Technologies
Section F, Huawei Industrial Base,
Bantian Longgang, Shenzhen  518129
P.R. China

Phone: +86 15013838060
EMail: huangfuqing@huawei.com

Georgios Karagiannis is at the University of Twente in the Netherlands 🇳🇱 🧚. Here's where to find him:

Georgios Karagiannis
University of Twente
P.O. Box 217
7500 AE Enschede,
The Netherlands

Phone: +31 53 4894099
EMail: g.karagiannis@utwente.nl

Michael Menth is at the University of Tuebingen in Germany 🇩🇪 🦋. Contact details below, periodt:

Michael Menth
University of Tuebingen
Sand 13
72076 Tuebingen
Germany

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

Last but definitely not least, Tom Taylor is the editor 👑 ✨. He's also at Huawei Technologies, this time in Ottawa, Canada 🍁. The email is tom.taylor.stds@gmail.com 💅

Tom Taylor (editor)
Huawei Technologies
Ottawa
Canada

EMail: tom.taylor.stds@gmail.com

That's the whole RFC, bestie! 🌈💖 Four brilliant authors, one very serious spec, and so much networking knowledge it's giving main character energy 🎀

📦 where this page comes from