| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
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 July 18, 2009.
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.
.
.
.
.
1.
Introduction
2.
Terminology
3.
Benefits
4.
Deployment scenarios
5.
Assumptions and constraints on scope
5.1.
Assumption 1: Trust and support of PCN - controlled environment
5.2.
Assumption 2: Real-time applications
5.3.
Assumption 3: Many flows and additional load
5.4.
Assumption 4: Emergency use out of scope
6.
High-level functional architecture
6.1.
Flow admission
6.2.
Flow termination
6.3.
Flow admission and/or flow termination when there are only two PCN encoding states
6.4.
Information transport
6.5.
PCN-traffic
6.6.
Backwards compatibility
7.
Detailed Functional architecture
7.1.
PCN-interior-node functions
7.2.
PCN-ingress-node functions
7.3.
PCN-egress-node functions
7.4.
Admission control functions
7.5.
Flow termination functions
7.6.
Addressing
7.7.
Tunnelling
7.8.
Fault handling
8.
Challenges
9.
Operations and Management
9.1.
Configuration OAM
9.1.1.
System options
9.1.2.
Parameters
9.2.
Performance & Provisioning OAM
9.3.
Accounting OAM
9.4.
Fault OAM
9.5.
Security OAM
10.
IANA Considerations
11.
Security considerations
12.
Conclusions
13.
Acknowledgements
14.
Comments Solicited
15.
Changes
15.1.
Changes from -08 to -09
15.2.
Changes from -07 to -08
15.3.
Changes from -06 to -07
15.4.
Changes from -05 to -06
15.5.
Changes from -04 to -05
15.6.
Changes from -03 to -04
15.7.
Changes from -02 to -03
15.8.
Changes from -01 to -02
15.9.
Changes from -00 to -01
16.
Appendix: Possible future work items
16.1.
Probing
16.1.1.
Introduction
16.1.2.
Probing functions
16.1.3.
Discussion of rationale for probing, its downsides and open issues
17.
References
17.1.
Normative References
17.2.
Informative References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
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 [RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.). This document defines an architecture for implementing two mechanisms to protect the quality of service of established inelastic flows within a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and are trusted for correct PCN operation. Flow admission control determines whether a new flow should be admitted, in order to protect the QoS of existing PCN-flows in normal circumstances. 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. Therefore this document also describes a mechanism for flow termination, which removes enough traffic in order to protect the QoS of the remaining PCN-flows.
As a fundamental building block to enable these two mechanisms, PCN-interior-nodes generate, encode and transport pre-congestion information towards the PCN-egress-nodes. Two rates, a PCN-threshold-rate and a PCN-excess-rate, are associated with each link of the PCN-domain. Each rate is used by a marking behaviour that determines how and when PCN-packets are marked, and how the markings are encoded in packet headers. Overall the aim is to enable PCN-nodes to give an "early warning" of potential congestion before there is any significant build-up of PCN-packets in the queue.
PCN-boundary-nodes convert measurements of these PCN-markings into decisions about flow admission and termination. In a PCN-domain with both threshold marking and excess traffic marking enabled, then the admission control mechanism limits the PCN-traffic on each link to *roughly* its PCN-threshold-rate and the flow termination mechanism limits the PCN-traffic on each link to *roughly* its PCN-excess-rate. Other scenarios are discussed later.
The behaviour of PCN-interior-nodes is standardised in other documents, which are summarised in this document:
The behaviour of PCN-boundary-nodes is described in Informational documents. Several 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.).
This document describes the PCN architecture at a high level (Section 6) and in more detail (Section 7). It also defines some terminology and outlines some benefits, deployment scenarios, and assumptions of PCN (Sections 2-5). Finally it outlines some challenges, operations and management, and security considerations, and some potential future work items (Sections 8, 9, 11 and Appendix).
| TOC |
| TOC |
We believe that the key benefits of the PCN mechanisms described in this document are that they are simple, scalable, and robust because:
| TOC |
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.
From the perspective of the outside world, a PCN-domain essentially looks like a DiffServ domain. 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.
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.
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.
==Marking behaviour== ==PCN mechanisms==
Rate of ^
PCN-traffic on |
bottleneck link | (as below and also)
| (as below) Drop some PCN-pkts
|
scheduler rate -|------------------------------------------------
(for PCN-traffic) |
| 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: Schematic of how the PCN admission control and flow termination mechanisms operate as the rate of PCN-traffic increases, for a PCN-domain with three encoding states.
On the other hand, a PCN-domain may have two encoding states (as in [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information,” 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 6.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.).
Within the PCN-domain there is some flexibility about how the decision making functionality is distributed. These possibilities are outlined in Section 7.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.
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 7.7.
Some further possible deployment models are outlined in the Appendix.
| TOC |
The scope is restricted by the following assumptions:
| TOC |
We assume 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:
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.
| TOC |
We assume 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-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.
| TOC |
We assume 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.
We do not make explicit assumptions on 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.
| TOC |
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.
| TOC |
The high-level approach is to split functionality between:
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:
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).
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 7.4 and 7.5 mention various possibilities for how the functionality could be distributed.
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] (, “Marking behaviour of PCN-nodes (work in progress),” Oct 2008.) for further discussion.
The objective of the threshold-marking 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 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 algorithm rather than its 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] (, “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. It initially assumes there are three encoding states available.
| TOC |
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):
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.
| TOC |
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):
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.
| TOC |
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,” Oct 2008.), then an operator has three options (others might be possible):
==Marking behaviour== ==PCN mechanisms==
Rate of ^
PCN-traffic on |
bottleneck link | Terminate some
| Further pkts admitted flows
| excess-traffic-marked &
| Block new flows
|
|
U*PCN-excess-rate -|------------------------------------------------
(=PCN-supportable-rate)|
| Some pkts Block new flows
| excess-traffic-marked
|
PCN-excess-rate -|------------------------------------------------
(=PCN-admissible-rate)|
| No pkts Admit new flows
| PCN-marked
|
Figure 2: 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.
| TOC |
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 between the PCN-boundary-nodes, 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.
| TOC |
The following are some high-level points about how PCN works:
traffic that is priority scheduled over PCN (perhaps a particular application or an operator's control messages).
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).
| TOC |
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:
For the baseline encoding [PCN08‑1] (, “Baseline Encoding and Transport of Pre-Congestion Information,” 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 take different 'appropriate action'.
| TOC |
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:
Note: Probing is covered in the Appendix.
The section then discusses some other detailed topics:
| TOC |
Each link of the PCN-domain is configured with the following functionality:
The functions are defined in [PCN08‑2] (, “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,” Oct 2008.) (extended encodings are to be defined in other documents).
| TOC |
Each ingress link of the PCN-domain is configured with the following functionality:
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.
| TOC |
Each egress link of the PCN-domain is configured with the following functionality:
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,” Oct 2008.) specifies that the PCN-egress-node re-sets the ECN field to 00; other encodings may define different behaviour.
| TOC |
As well as the functions covered above, other specific admission control functions need to be performed (others might be possible):
There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used):
Note: Admission control functionality is not performed by normal PCN-interior-nodes.
| TOC |
As well as the functions covered above, other specific termination control functions need to be performed (others might be possible):
There are various possibilities for how the functionality could be distributed, similar to those discussed above in the Admission control section.
| TOC |
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.
| TOC |
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] (, “Layered Encapsulation of Congestion Notification (work in progress),” July 2008.), the following rule is applied if encapsulation is done within the PCN-domain:
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:
Note: the order of increasing severity is: not PCN-marked; threshold-marking; excess-traffic-marking.
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 7.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. 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:
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:
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,” 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] (, “Layered Encapsulation of Congestion Notification (work in progress),” July 2008.).
| TOC |
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] (, “Layered Encapsulation of Congestion Notification (work in progress),” July 2008.) considers what happens if RSVP is the QoS signalling protocol.
| TOC |
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.
| TOC |
This Section considers operations and management issues, under the FCAPS headings: OAM of Faults, Configuration, Accounting, Performance and Security. Provisioning is discussed with performance.
| TOC |
Threshold-marking and excess-traffic-marking are standardised in [PCN08‑2] (, “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.
A PCN marking behaviour (threshold-marking, excess-traffic-marking) 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:
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.
| TOC |
On PCN-interior-nodes there will be very few system options:
PCN-boundary-nodes (ingress and egress) will have more system options:
PCN-egress-nodes will have further system options:
| TOC |
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 9.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-marking requires a threshold token bucket depth to be configured, excess-traffic-marking 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:
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:
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.
| TOC |
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.
| TOC |
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.
| TOC |
Fault OAM 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 7 (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 9.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.
| TOC |
Security OAM 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 9.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 MOS 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:
| TOC |
This memo includes no request to IANA.
| TOC |
Security considerations essentially come from the Trust Assumption (Section 5.1), ie that all PCN-nodes are PCN-enabled and are trusted for truthful PCN-marking and transport. 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.
Operational security advice is given in Section 9.5.
| TOC |
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.
| TOC |
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, Scott Bradner, Bob Briscoe, Jason Canon, Ken Carlberg, Anna Charny, Joachim Charzinski, Andras Csaszar, Lars Eggert, Ruediger Geib, Wei Gengyu, Robert Hancock, Fortune Huang, Christian Hublet, Ingemar Johansson, Georgios Karagiannis, Hein Mekkes, Michael Menth, Toby Moncaster, Daisuke Satoh, Ben Strulo, Tom Taylor, Hannes Tschofenig, Tina Tsou, 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.
| TOC |
Comments and questions are encouraged and very welcome. They can be addressed to the IETF PCN working group mailing list <pcn@ietf.org>.
| TOC |
| TOC |
Small changes to deal with WG Chair comments:
| TOC |
Small changes from second WG last call:
| TOC |
References re-formatted to pass ID nits. No other changes.
| TOC |
Minor clarifications throughout, the least insignificant are as follows:
| TOC |
Minor nits removed as follows:
| TOC |
| TOC |
| TOC |
| TOC |
In addition to clarifications and nit squashing, the main changes are:
| TOC |
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 5:
Other possibilities include:
| TOC |
| TOC |
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.
| TOC |
The probing functions are:
| TOC |
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:
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:
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:
(2) If admission control is based on measurements of pre-congestion on specific ECMP paths, then the viewpoint that probing is useful assumes:
The downsides of probing for this viewpoint are:
The open issues associated with this viewpoint include:
| TOC |
| TOC |
| [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 (TXT, HTML, XML). |
| [RFC3246] | Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, “An Expedited Forwarding PHB (Per-Hop Behavior),” RFC 3246, March 2002 (TXT). |
| TOC |
| [RFC1633] | Braden, B., Clark, D., and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” RFC 1633, June 1994 (TXT, PS, PDF). |
| [RFC2211] | Wroclawski, J., “Specification of the Controlled-Load Network Element Service,” RFC 2211, September 1997 (TXT, HTML, XML). |
| [RFC2475] | Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” RFC 2475, December 1998 (TXT, HTML, XML). |
| [RFC2747] | Baker, F., Lindell, B., and M. Talwar, “RSVP Cryptographic Authentication,” RFC 2747, January 2000 (TXT). |
| [RFC2753] | Yavatkar, R., Pendarakis, D., and R. Guerin, “A Framework for Policy-based Admission Control,” RFC 2753, January 2000 (TXT). |
| [RFC2983] | Black, D., “Differentiated Services and Tunnels,” RFC 2983, October 2000 (TXT). |
| [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,” RFC 2998, November 2000 (TXT). |
| [RFC3168] | Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” RFC 3168, September 2001 (TXT). |
| [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,” RFC 3270, May 2002 (TXT). |
| [RFC3393] | Demichelis, C. and P. Chimento, “IP Packet Delay Variation Metric for IP Performance Metrics (IPPM),” RFC 3393, November 2002 (TXT). |
| [RFC3411] | Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” STD 62, RFC 3411, December 2002 (TXT). |
| [RFC4216] | Zhang, R. and J. Vasseur, “MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements,” RFC 4216, November 2005 (TXT). |
| [RFC4301] | Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” RFC 4301, December 2005 (TXT). |
| [RFC4303] | Kent, S., “IP Encapsulating Security Payload (ESP),” RFC 4303, December 2005 (TXT). |
| [RFC4594] | Babiarz, J., Chan, K., and F. Baker, “Configuration Guidelines for DiffServ Service Classes,” RFC 4594, August 2006 (TXT). |
| [RFC4656] | Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, “A One-way Active Measurement Protocol (OWAMP),” RFC 4656, September 2006 (TXT). |
| [RFC4774] | Floyd, S., “Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field,” BCP 124, RFC 4774, November 2006 (TXT). |
| [RFC4778] | Kaeo, M., “Operational Security Current Practices in Internet Service Provider Environments,” RFC 4778, January 2007 (TXT). |
| [RFC5129] | Davie, B., Briscoe, B., and J. Tay, “Explicit Congestion Marking in MPLS,” RFC 5129, January 2008 (TXT). |
| [P.800] | “Methods for subjective determination of transmission quality,” ITU-T Recommendation P.800, August 1996. |
| [Y.1541] | “Network Performance Objectives for IP-based Services,” ITU-T Recommendation Y.1541, February 2006. |
| [MPLS08] | “Multi-Protocol Label Switching (MPLS) label stack entry: "EXP" field renamed to "Traffic Class" field (work in progress),” Dec 2008. |
| [PCN08-1] | “Baseline Encoding and Transport of Pre-Congestion Information,” Oct 2008. |
| [PCN08-2] | “Marking behaviour of PCN-nodes (work in progress),” Oct 2008. |
| [PWE3-08] | “Pseudowire Congestion Control Framework (work in progress),” May 2008. |
| [Babiarz06] | “SIP Controlled Admission and Preemption (work in progress),” Oct 2006. |
| [Behringer07] | “Applicability of Keying Methods for RSVP Security (work in progress),” Nov 2007. |
| [Briscoe06] | “An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region (work in progress),” October 2006. |
| [Briscoe08-1] | “Emulating Border Flow Policing using Re-PCN on Bulk Data (work in progress),” Sept 2008. |
| [Briscoe08-2] | “Layered Encapsulation of Congestion Notification (work in progress),” July 2008. |
| [Charny07-1] | “Comparison of Proposed PCN Approaches (work in progress),” November 2007. |
| [Charny07-2] | “Pre-Congestion Notification Using Single Marking for Admission and Termination (work in progress),” November 2007. |
| [Charny07-3] | “Email to PCN WG mailing list,” November 2007. |
| [Charny08] | “Email to PCN WG mailing list,” March 2008. |
| [Eardley07] | “Email to PCN WG mailing list,” October 2007. |
| [Hancock02] | “Slide 14 of 'NSIS: An Outline Framework for QoS Signalling',” May 2002. |
| [Iyer03] | “An approach to alleviate link overload as observed on an IP backbone,” IEEE INFOCOM , 2003. |
| [Lefaucheur06] | “RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification (PCN) (work in progress),” June 2006. |
| [Menth07] | “PCN-Based Resilient Network Admission Control: The Impact of a Single Bit",” Technical Report , 2007. |
| [Menth08-1] | “Edge-Assisted Marked Flow Termination (work in progress),” February 2008. |
| [Menth08-2] | “PCN Encoding for Packet-Specific Dual Marking (PSDM) (work in progress),” July 2008. |
| [Menth08-3] | “PCN-Based Admission Control and Flow Termination,” 2008. |
| [Moncaster08] | “A three state extended PCN encoding scheme (work in progress),” June 2008. |
| [Sarker08] | “Usecases and Benefits of end to end ECN support in PCN Domains (work in progress),” November 2008. |
| [Songhurst06] | “Guaranteed QoS Synthesis for Admission Control with Shared Capacity,” BT Technical Report TR-CXR9-2006-001, Feburary 2006. |
| [Style] | “Guardian Style,” Note: This document uses the abbreviations 'ie' and 'eg' (not 'i.e.' and 'e.g.'), as in many style guides, eg, 2007. |
| [Tsou08] | “Applicability Statement for the Use of Pre-Congestion Notification in a Resource-Controlled Network (work in progress),” November 2008. |
| [Westberg08] | “LC-PCN: The Load Control PCN Solution (work in progress),” November 2008. |
| TOC |
| Philip Eardley | |
| BT | |
| B54/77, Sirius House Adastral Park Martlesham Heath | |
| Ipswich, Suffolk IP5 3RE | |
| United Kingdom | |
| Email: | philip.eardley@bt.com |
| TOC |
Copyright © The IETF Trust (2009).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.