"Baseline Encoding and Transport of Pre-Congestion Information", T Moncaster, Bob Briscoe, Michael Menth, 20-May-09. ( bytes)
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. The level of marking allows the boundary nodes to make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, Not-marked and PCN-marked.
"Metering and marking behaviour of PCN-nodes", Philip Eardley, 3-Aug-09. ( bytes)
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. This document defines the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows.
"A PCN encoding using 2 DSCPs to provide 3 or more states", T Moncaster, Bob Briscoe, Michael Menth, 8-Apr-09. ( bytes)
Pre-congestion notification (PCN) is a mechanism designed to protect the Quality of Service of inelastic flows within a controlled domain. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This experimental encoding scheme specifies how three encoding states can be carried in the IP header using a combination of two DSCPs and the ECN bits. The Basic scheme only allows for three encoding states. The Full scheme additionally provides limited end-to-end support for ECN. Status (to be removed by RFC Editor) This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. The PCN Working Group will be asked to adopt this memo as a Working Group document describing one of several possible experimental PCN encoding schemes. The intention is that the title of this document will change to avoid confusion with the three state marking scheme. Changes from previous drafts From draft-moncaster-pcn-3-state-encoding-01: o Changed to WG draft. Title changed from "A three state extended PCN encoding scheme" o Imposed new structure on document. This structure is intended to be followed by all extensions to the baseline PCN encoding scheme. o Extensive changes throughout to ensure consistency with the baseline PCN encoding scheme. From 00 to 01: o Checked terminology for consistency with [I-D.ietf-pcn-baseline-encoding] o Minor editorial changes.
"PCN 3-State Encoding Extension in a single DSCP", Bob Briscoe, T Moncaster, 1-Jul-09. ( bytes)
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. The level of marking allows the boundary nodes to make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within this controlled domain. This encoding builds on the baseline encoding and provides for three PCN encoding states: Not-marked, Threshold-marked and Excess-traffic-marked.
"PCN Encoding for Packet-Specific Dual Marking (PSDM)", Michael Menth, Jozef Babiarz, T Moncaster, Bob Briscoe, 26-Jun-09. ( bytes)
This document proposes how PCN marks can be encoded into the IP header. The presented encoding reuses the ECN field of the Voice- Admit DSCP in a single PCN domain. The encoding of unmarked PCN packets indicates whether they are subject to either excess- or exhaustive-marking. This is useful, e.g., when data and probe packets require different marking mechanisms. Status This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC.
"Pre-Congestion Notification Encoding Comparison", Kwok Chan, Georgios Karagiannis, T Moncaster, Michael Menth, Philip Eardley, Bob Briscoe, 6-Jul-09. ( bytes)
A number of mechanisms have been proposed to support differential Qualiy of Service for packets in the Internet. DiffServ is an example of such a mechanism. However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre-Congestion Notification (PCN) uses path congestion information across a PCN region to enable per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under normal operating conditions, an additional flow termination mechanism is necessary to cope with extreme events (e.g. route changes due to link or node failure). In order to allow the PCN mechanisms to work it is necessary for IP packets to be able to carry the pre-congestion information to the PCN egress nodes. This document collects the lessons learned as we explores the different ways in which this information can be encoded into IP packets. This document does not choose the encoding but provide information on trade offs with the encoding choices, providing guidance based on different criteria. This document provides a historical trace of the consideration on different encoding alternatives for Pre-Congestion Notification.
"PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation", Anna Charny, Fortune Huang, Georgios Karagiannis, Michael Menth, Tom Taylor, 6-Jul-09. ( bytes)
Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN domain. The behaviour described here is that for three-state measurement-based load control, known informally as Controlled Load (CL).
"PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation", Anna Charny, Georgios Karagiannis, Michael Menth, Tom Taylor, 6-Jul-09. ( bytes)
Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN domain. The behaviour described here is that for two-state measurement-based load control, known informally as Single Marking (SM).

IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

Return to Internet-Draft directory.

Return to IETF home page.