draft-ietf-pcn-architecture-03.txt   draft-ietf-pcn-architecture-04.txt 
Congestion and Pre-Congestion Philip. Eardley (Editor) Congestion and Pre-Congestion Philip. Eardley (Editor)
Notification Working Group BT Notification Working Group BT
Intended status: Informational Intended status: Informational
Expires: August 11, 2008 Expires: January 15, 2009
Pre-Congestion Notification Architecture Pre-Congestion Notification Architecture
draft-ietf-pcn-architecture-03 draft-ietf-pcn-architecture-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 11, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The purpose of this document is to describe a general architecture The purpose of this document is to describe a general architecture
for flow admission and termination based on pre-congestion for flow admission and termination based on pre-congestion
information in order to protect the quality of service of established information in order to protect the quality of service of established
inelastic flows within a single DiffServ domain. inelastic flows within a single DiffServ domain.
Status Status
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Assumptions and constraints on scope . . . . . . . . . . . . . 9 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Assumption 1: Trust and support of PCN - controlled 4. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 8
environment . . . . . . . . . . . . . . . . . . . . . . . 9 5. Assumptions and constraints on scope . . . . . . . . . . . . . 10
3.2. Assumption 2: Real-time applications . . . . . . . . . . . 10 5.1. Assumption 1: Trust and support of PCN - controlled
3.3. Assumption 3: Many flows and additional load . . . . . . . 10 environment . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Assumption 4: Emergency use out of scope . . . . . . . . . 11 5.2. Assumption 2: Real-time applications . . . . . . . . . . . 11
3.5. Other assumptions . . . . . . . . . . . . . . . . . . . . 11 5.3. Assumption 3: Many flows and additional load . . . . . . . 12
4. High-level functional architecture . . . . . . . . . . . . . . 11 5.4. Assumption 4: Emergency use out of scope . . . . . . . . . 12
4.1. Flow admission . . . . . . . . . . . . . . . . . . . . . . 12 6. High-level functional architecture . . . . . . . . . . . . . . 12
4.2. Flow termination . . . . . . . . . . . . . . . . . . . . . 13 6.1. Flow admission . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Flow admission and flow termination . . . . . . . . . . . 14 6.2. Flow termination . . . . . . . . . . . . . . . . . . . . . 15
4.4. Information transport . . . . . . . . . . . . . . . . . . 15 6.3. Flow admission and flow termination when there are
4.5. PCN-traffic . . . . . . . . . . . . . . . . . . . . . . . 15 only two PCN encoding states . . . . . . . . . . . . . . . 16
5. Detailed Functional architecture . . . . . . . . . . . . . . . 16 6.4. Information transport . . . . . . . . . . . . . . . . . . 16
5.1. PCN-interior-node functions . . . . . . . . . . . . . . . 17 6.5. PCN-traffic . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. PCN-ingress-node functions . . . . . . . . . . . . . . . . 17 6.6. Backwards compatibility . . . . . . . . . . . . . . . . . 17
5.3. PCN-egress-node functions . . . . . . . . . . . . . . . . 18 7. Detailed Functional architecture . . . . . . . . . . . . . . . 18
5.4. Other admission control functions . . . . . . . . . . . . 19 7.1. PCN-interior-node functions . . . . . . . . . . . . . . . 19
5.5. Other flow termination functions . . . . . . . . . . . . . 19 7.2. PCN-ingress-node functions . . . . . . . . . . . . . . . . 19
5.6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. PCN-egress-node functions . . . . . . . . . . . . . . . . 20
5.7. Tunnelling . . . . . . . . . . . . . . . . . . . . . . . . 21 7.4. Other admission control functions . . . . . . . . . . . . 20
5.8. Fault handling . . . . . . . . . . . . . . . . . . . . . . 22 7.5. Other flow termination functions . . . . . . . . . . . . . 21
6. Design goals and challenges . . . . . . . . . . . . . . . . . 23 7.6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.7. Tunnelling . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 25 7.8. Fault handling . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Probing functions . . . . . . . . . . . . . . . . . . . . 26 8. Design goals and challenges . . . . . . . . . . . . . . . . . 24
7.3. Discussion of rationale for probing, its downsides and 9. Operations and Management . . . . . . . . . . . . . . . . . . 27
open issues . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Configuration OAM . . . . . . . . . . . . . . . . . . . . 27
8. Operations and Management . . . . . . . . . . . . . . . . . . 30 9.1.1. System options . . . . . . . . . . . . . . . . . . . . 28
8.1. Configuration OAM . . . . . . . . . . . . . . . . . . . . 30 9.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . . 29
8.1.1. System options . . . . . . . . . . . . . . . . . . . . 31 9.2. Performance & Provisioning OAM . . . . . . . . . . . . . . 31
8.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . . 31 9.3. Accounting OAM . . . . . . . . . . . . . . . . . . . . . . 32
8.2. Performance & Provisioning OAM . . . . . . . . . . . . . . 33 9.4. Fault OAM . . . . . . . . . . . . . . . . . . . . . . . . 32
8.3. Accounting OAM . . . . . . . . . . . . . . . . . . . . . . 34 9.5. Security OAM . . . . . . . . . . . . . . . . . . . . . . . 33
8.4. Fault OAM . . . . . . . . . . . . . . . . . . . . . . . . 34 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8.5. Security OAM . . . . . . . . . . . . . . . . . . . . . . . 35 11. Security considerations . . . . . . . . . . . . . . . . . . . 34
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 35
10. Security considerations . . . . . . . . . . . . . . . . . . . 36 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37 14. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 36
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 15. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
13. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 38 15.1. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 36
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 15.2. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 37
14.1. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 38 15.3. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 38
14.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 39 15.4. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 39
14.3. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 40 16. Appendix A: Possible work items beyond the scope of the
15. Appendix A: Possible work items beyond the scope of the current PCN WG Charter . . . . . . . . . . . . . . . . . . . . 40
current PCN WG Charter . . . . . . . . . . . . . . . . . . . . 42 17. Appendix B: Probing . . . . . . . . . . . . . . . . . . . . . 42
16. Informative References . . . . . . . . . . . . . . . . . . . . 44 17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 17.2. Probing functions . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 48 17.3. Discussion of rationale for probing, its downsides and
open issues . . . . . . . . . . . . . . . . . . . . . . . 43
18. Informative References . . . . . . . . . . . . . . . . . . . . 46
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51
Intellectual Property and Copyright Statements . . . . . . . . . . 52
1. Introduction 1. Introduction
The purpose of this document is to describe a general architecture The purpose of this document is to describe a general architecture
for flow admission and termination based on (pre-) congestion for flow admission and termination based on (pre-) congestion
information in order to protect the quality of service of flows information in order to protect the quality of service of flows
within a DiffServ domain [RFC2475]. This document defines an within a DiffServ domain [RFC2475]. This document defines an
architecture for implementing two mechanisms to protect the quality architecture for implementing two mechanisms to protect the quality
of service of established inelastic flows within a single DiffServ of service of established inelastic flows within a single DiffServ
domain, where all boundary and interior nodes are PCN-enabled and domain, where all boundary and interior nodes are PCN-enabled and
trust each other for correct PCN operation. Flow admission control trust each other for correct PCN operation. Flow admission control
determines whether a new flow should be admitted, in order to protect determines whether a new flow should be admitted, in order to protect
the QoS of existing PCN-flows in normal circumstances. However, in the QoS of existing PCN-flows in normal circumstances. However, in
abnormal circumstances, for instance a disaster affecting multiple abnormal circumstances, for instance a disaster affecting multiple
nodes and causing traffic re-routes, then the QoS on existing PCN- nodes and causing traffic re-routes, then the QoS on existing PCN-
flows may degrade even though care was exercised when admitting those flows may degrade even though care was exercised when admitting those
flows before those circumstances. Therefore we also propose a flows. Therefore we also propose a mechanism for flow termination,
mechanism for flow termination, which removes enough traffic in order which removes enough traffic in order to protect the QoS of the
to protect the QoS of the remaining PCN-flows. remaining PCN-flows.
As a fundamental building block to enable these two mechanisms, PCN- As a fundamental building block to enable these two mechanisms, PCN-
interior-nodes generate, encode and transport pre-congestion interior-nodes generate, encode and transport pre-congestion
information towards the PCN-egress-nodes. Two rates, a PCN-lower- information towards the PCN-egress-nodes. Two rates, a PCN-
rate and a PCN-upper-rate, can be associated with each link of the threshold-rate and a PCN-excess-rate, are associated with each link
PCN-domain. Each rate is used by a marking behaviour (specified in of the PCN-domain. Each rate is used by a marking behaviour that
another document) that determines how and when a number of PCN- determines how and when PCN-packets are marked, and how the markings
packets are marked, and how the markings are encoded in packet are encoded in packet headers. Overall the aim is to enable PCN-
headers. PCN-egress-nodes make measurements of the packet markings nodes to give an "early warning" of potential congestion before there
and send information as necessary to the nodes that make the decision is any significant build-up of PCN-packets in the queue.
about which PCN-flows to accept/reject or terminate, based on this
information. Another document will describe the decision-making PCN-boundary-nodes convert measurements of these PCN-markings into
behaviours. Overall the aim is to enable PCN-nodes to give an "early decisions about flow admission and termination. 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.
This document describes the PCN architecture and outlines some
benefits, deployment scenarios, assumptions and terminology for PCN.
The behaviour of PCN-interior-nodes is standardised in three
documents, which are summarised in this
document.[I-D.eardley-pcn-marking-behaviour] standardises the two
marking behaviours of PCN-nodes: threshold marking and excess traffic
marking. Threshold marking marks all PCN-packets if the PCN traffic
rate is greater than a first configured rate, "PCN-threshold-rate".
Excess traffic marking marks a proportion of PCN-packets, such that
the amount marked equals the traffic rate in excess of a second
configured rate, "PCN-excess-rate". PCN encoding uses a combination
of the DSCP field and ECN field in the IP header to indicate that a
packet is a PCN-packet and whether it is PCN-marked.
[I-D.moncaster-pcn-baseline-encoding] standardises two PCN encoding
states (PCN-marked and not PCN-marked) whilst
[I-D.moncaster-pcn-3-state-encoding] standardises an extended scheme
with three encoding states (threshold-marked, excess-traffic-marked,
not PCN-marked) but requires an extra DiffServ codepoint. PCN
therefore defines semantics for the ECN field different from the
default semantics of [RFC3168]; PCN's encoding has been chosen to
meet the guidelines of BCP124, [RFC4774]. The behaviour of PCN-
boundary-nodes is described in Informational documents. Several
possibilities are outlined in this document; detailed descriptions
and comparisons are in [I-D.charny-pcn-comparison] and [Menth08].
2. Terminology
o PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled
nodes that perform DiffServ scheduling; the complete set of PCN-
nodes whose PCN-marking can in principle influence decisions about
flow admission and termination for the PCN-domain, including the
PCN-egress-nodes which measure these PCN-marks.
o PCN-boundary-node: a PCN-node that connects one PCN-domain to a
node either in another PCN-domain or in a non PCN-domain.
o PCN-interior-node: a node in a PCN-domain that is not a PCN-
boundary-node.
o PCN-node: a PCN-boundary-node or a PCN-interior-node
o PCN-egress-node: a PCN-boundary-node in its role in handling
traffic as it leaves a PCN-domain.
o PCN-ingress-node: a PCN-boundary-node in its role in handling
traffic as it enters a PCN-domain.
o PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic of
different DiffServ behaviour aggregates (BAs) [RFC2475]. The
PCN-BA uses the PCN mechanisms to carry PCN-traffic and the
corresponding packets are PCN-packets. The same network will
carry traffic of other DiffServ BAs. The PCN-BA is distinguished
by a combination of the DiffServ codepoint (DSCP) and ECN fields;
note that a packet that shares the same DSCP as PCN-traffic but
its ECN field is 00 (Not ECT) is not part of the PCN-BA.
o PCN-flow: the unit of PCN-traffic that the PCN-boundary-node
admits (or terminates); the unit could be a single microflow (as
defined in [RFC2475]) or some identifiable collection of
microflows.
o Ingress-egress-aggregate: The collection of PCN-packets from all
PCN-flows that travel in one direction between a specific pair of
PCN-boundary-nodes.
o PCN-threshold-rate: a reference rate configured for each link in
the PCN-domain, which is lower than the PCN-excess-rate. It is
used by a marking behaviour that determines whether a packet
should be PCN-marked with a first encoding, "threshold-marked".
It's roughly the rate up to which PCN admission control should
accept new flows.
o PCN-excess-rate: a reference rate configured for each link in the
PCN-domain, which is higher than the PCN-threshold-rate. It is
used by a marking behaviour that determines whether a packet
should be PCN-marked with a second encoding, "excess-traffic-
marked". It's roughly that rate down to which flow termination
should, if necessary, terminate already admitted flows.
o Threshold-marking: a PCN-marking behaviour with the objective that
all PCN-traffic is marked if the PCN-traffic exceeds the PCN-
threshold-rate.
o Excess-traffic-marking: a PCN-marking behaviour with the objective
that the amount of PCN-traffic that is PCN-marked is equal to the
amount that exceeds the PCN-excess-rate.
o Pre-congestion: a condition of a link within a PCN-domain in which
the PCN-node performs PCN-marking, in order to provide an "early
warning" of potential congestion before there is any significant warning" of potential congestion before there is any significant
build-up of PCN-packets in the queue; the admission control mechanism build-up of PCN-packets in the real queue. (Hence, by analogy
limits the PCN-traffic on each link to *roughly* its PCN-lower-rate with ECN we call our mechanism Pre-Congestion Notification.)
and the flow termination mechanism limits the PCN-traffic on each
link to *roughly* its PCN-upper-rate. o PCN-marking: the process of setting the header in a PCN-packet
based on defined rules, in reaction to pre-congestion; either
threshold-marking or excess-traffic-marking.
o PCN-feedback-information: information signalled by a PCN-egress-
node to a PCN-ingress-node or central control node, which is
needed for the flow admission and flow termination mechanisms.
3. Benefits
We believe that the key benefits of the PCN mechanisms described in We believe that the key benefits of the PCN mechanisms described in
this document are that they are simple, scalable, and robust because: this document are that they are simple, scalable, and robust because:
o Per flow state is only required at the PCN-ingress-nodes o Per flow state is only required at the PCN-ingress-nodes
("stateless core"). This is required for policing purposes (to ("stateless core"). This is required for policing purposes (to
prevent non-admitted PCN traffic from entering the PCN-domain) and prevent non-admitted PCN traffic from entering the PCN-domain) and
so on. It is not generally required that other network entities so on. It is not generally required that other network entities
are aware of individual flows (although they may be in particular are aware of individual flows (although they may be in particular
deployment scenarios). deployment scenarios).
o Admission control is resilient: PCN's QoS is decoupled from the o Admission control is resilient: PCN's QoS is decoupled from the
routing system; hence in general admitted flows can survive routing system; hence in general admitted flows can survive
capacity, routing or topology changes without additional capacity, routing or topology changes without additional
signalling, and they don't have to be told (or learn) about such signalling, and they don't have to be told (or learn) about such
changes. The PCN-lower-rates can be chosen small enough that changes. The PCN-threshold-rate on each PCN-node can be chosen
admitted traffic can still be carried after a rerouting in most small enough that admitted traffic can still be carried after a
failure cases [Menth]. This is an important feature as QoS rerouting in most failure cases [Menth]. This is an important
violations in core networks due to link failures are more likely feature as QoS violations in core networks due to link failures
than QoS violations due to increased traffic volume [Iyer]. are more likely than QoS violations due to increased traffic
volume [Iyer].
o The PCN-marking behaviours only operate on the overall PCN-traffic o The PCN-marking behaviours only operate on the overall PCN-traffic
on the link, not per flow. on the link, not per flow.
o The information of these measurements is signalled to the PCN- o The information of these measurements is signalled to the PCN-
egress-nodes by the PCN-marks in the packet headers, ie "in-band". egress-nodes by the PCN-marks in the packet headers, ie "in-band".
No additional signalling protocol is required for transporting the No additional signalling protocol is required for transporting the
PCN-marks. Therefore no secure binding is required between data PCN-marks. Therefore no secure binding is required between data
packets and separate congestion messages. packets and separate congestion messages.
skipping to change at page 5, line 50 skipping to change at page 8, line 7
o The termination mechanism complements admission control. It o The termination mechanism complements admission control. It
allows the network to recover from sudden unexpected surges of allows the network to recover from sudden unexpected surges of
PCN-traffic on some links, thus restoring QoS to the remaining PCN-traffic on some links, thus restoring QoS to the remaining
flows. Such scenarios are expected to be rare but not impossible. flows. Such scenarios are expected to be rare but not impossible.
They can be caused by large network failures that redirect lots of They can be caused by large network failures that redirect lots of
admitted PCN-traffic to other links, or by malfunction of the admitted PCN-traffic to other links, or by malfunction of the
measurement-based admission control in the presence of admitted measurement-based admission control in the presence of admitted
flows that send for a while with an atypically low rate and then flows that send for a while with an atypically low rate and then
increase their rates in a correlated way. increase their rates in a correlated way.
o The PCN-upper-rate may be set below the maximum rate that PCN- o Flow termination can also enable an operator to be less
conservative when deploying network capacity. It is an
alternative to running links at low utilisation in order to
protect against link or node failures. This is especially the
case with SRLGs (shared risk link groups, which are links that
share a resource, such as a fibre, whose failure affects all those
links [RFC4216]. A requirement to fully protect traffic against a
single SRLG failure requires low utilisation (~10%) of the link
bandwidth on some links before failure [PCN-email-SRLG].
o The PCN-excess-rate may be set below the maximum rate that PCN-
traffic can be transmitted on a link, in order to trigger traffic can be transmitted on a link, in order to trigger
termination of some PCN-flows before loss (or excessive delay) of termination of some PCN-flows before loss (or excessive delay) of
PCN-packets occurs, or to keep the maximum PCN-load on a link PCN-packets occurs, or to keep the maximum PCN-load on a link
below a level configured by the operator. below a level configured by the operator.
o Provisioning of the network is decoupled from the process of o Provisioning of the network is decoupled from the process of
adding new customers. By contrast, with the DiffServ architecture adding new customers. By contrast, with the DiffServ architecture
[RFC2475] operators rely on subscription-time Service Level [RFC2475] operators rely on subscription-time Service Level
Agreements that statically define the parameters of the traffic Agreements that statically define the parameters of the traffic
that will be accepted from a customer, and so the operator has to that will be accepted from a customer, and so the operator has to
run the provisioning process each time a new customer is added to run the provisioning process each time a new customer is added to
check that the Service Level Agreement can be fulfilled. A PCN- check that the Service Level Agreement can be fulfilled. A PCN-
domain doesn't need such traffic conditioning. domain doesn't need such traffic conditioning.
4. Deployment scenarios
Operators of networks will want to use the PCN mechanisms in various Operators of networks will want to use the PCN mechanisms in various
arrangements, for instance depending on how they are performing arrangements, for instance depending on how they are performing
admission control outside the PCN-domain (users after all are admission control outside the PCN-domain (users after all are
concerned about QoS end-to-end), what their particular goals and concerned about QoS end-to-end), what their particular goals and
assumptions are, and so on. Several deployment models are possible: assumptions are, how many PCN encoding states are available, and so
on.
o An operator may choose to deploy either admission control or flow
termination or both (see Section 4.3).
o IntServ over DiffServ [RFC2998]. The DiffServ region is PCN-
enabled and the PCN-domain is a single RSVP hop, ie only the PCN-
boundary-nodes process RSVP messages. Outside the PCN-domain RSVP
messages are processed on each hop. The case where RSVP
signalling is used end-to-end is described in
[I-D.briscoe-tsvwg-cl-architecture]; 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).
o Similar to previous bullet but NSIS signalling is used instead of
RSVP.
o Depending on the deployment scenario, the decision-making
functionality (about flow admission and termination) could reside
at the PCN-ingress-nodes or PCN-egress-nodes or (see Appendix) at
some central control node in the PCN-domain.
o There are several PCN-domains on the end-to-end path, each
operating PCN mechanisms independently.
o The PCN-domain extends to the end users. The scenario is
described in [I-D.babiarz-pcn-sip-cap]. A variant is that the
PCN-domain extends out as far as the LAN edge switch.
o The operator runs both the access network (not a PCN-domain) and
the core network (a PCN-domain); per flow policing is devolved to
the access network and is 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.
o Pseudowire: PCN may be used as a congestion avoidance mechanism
for edge to edge pseudowire emulations
[I-D.ietf-pwe3-congestion-frmwk].
o MPLS: [RFC3270] defines how to support the DiffServ architecture
in MPLS networks. [RFC5129] describes how to add PCN for
admission control of microflows into a set of MPLS aggregates
(Multi-protocol label switching). PCN-marking is done in MPLS's
EXP field.
o Similarly, it may be possible to extend PCN into Ethernet
networks, where PCN-marking is done in the Ethernet header. NOTE:
Specific consideration of this extension is outside the IETF's
remit.
From the perspective of the outside world, a PCN-domain essentially From the perspective of the outside world, a PCN-domain essentially
looks like a DiffServ domain. PCN-traffic is either transported looks like a DiffServ domain. PCN-traffic is either transported
across it transparently or policed at the PCN-ingress-node (ie across it transparently or policed at the PCN-ingress-node (ie
dropped or carried at a lower QoS). A couple of differences are dropped or carried at a lower QoS). A couple of differences are
that: PCN-traffic has better QoS guarantees than normal DiffServ that: PCN-traffic has better QoS guarantees than normal DiffServ
traffic (because PCN's mechanisms better protect the QoS of admitted traffic (because PCN's mechanisms better protect the QoS of admitted
flows); and in rare circumstances (failures), on the one hand some flows); and in rare circumstances (failures), on the one hand some
PCN-flows may get terminated, but on the other hand other flows will PCN-flows may get terminated, but on the other hand other flows will
get their QoS restored. Non PCN-traffic is treated transparently, ie get their QoS restored. Non PCN-traffic is treated transparently, ie
the PCN-domain is a normal DiffServ domain. the PCN-domain is a normal DiffServ domain.
2. Terminology An operator may choose to deploy either admission control or flow
termination or both. Although designed to work together, they are
o PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled independent mechanisms, and the use of one does not require or
nodes that perform DiffServ scheduling; the compete set of PCN- prevent the use of the other.
nodes whose PCN-marking can in principle influence decisions about
flow admission and termination for the PCN-domain, including the
PCN-egress-nodes which measure these PCN-marks.
o PCN-boundary-node: a PCN-node that connects one PCN-domain to a
node either in another PCN-domain or in a non PCN-domain.
o PCN-interior-node: a node in a PCN-domain that is not a PCN-
boundary-node.
o PCN-node: a PCN-boundary-node or a PCN-interior-node
o PCN-egress-node: a PCN-boundary-node in its role in handling
traffic as it leaves a PCN-domain.
o PCN-ingress-node: a PCN-boundary-node in its role in handling
traffic as it enters a PCN-domain.
o PCN-traffic: A PCN-domain carries traffic of different DiffServ
behaviour aggregates [RFC2475]. Those using the PCN mechanisms
are called PCN-BAs (collectively called PCN-traffic) and the
corresponding packets are PCN-packets. The same network may carry
traffic using other DiffServ BAs. A PCN-flow is the unit of PCN-
traffic that the PCN-boundary-node admits (or terminates); the
unit could be a single microflow (as defined in [RFC2475]) or some
identifiable collection of microflows.
o Ingress-egress-aggregate: The collection of PCN-packets from all For example, an operator could use just PCN's admission control,
PCN-flows that travel in one direction between a specific pair of solving heavy congestion (caused by re-routing) by 'just waiting' -
PCN-boundary-nodes. 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 PCN-traffic naturally departs to relieve
the congestion, all PCN-flows as well as lower priority services will
be adversely affected.
o PCN-lower-rate: a reference rate configured for each link in the Another example is that an operator could just rely for admission
PCN-domain, which is lower than the PCN-upper-rate. It is used by control on statically provisioned capacity per PCN-ingress-node
a marking behaviour that determines whether a packet should be (regardless of the PCN-egress-node of a flow), as is typical in the
PCN-marked with a first encoding. hose model of the DiffServ architecture [RFC2475]. 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.
o PCN-upper-rate: a reference rate configured for each link in the The possibility of deploying just one of PCN's flow admission and
PCN-domain, which is higher than the PCN-lower-rate. It is used termination mechanisms is certainly an option when only two PCN
by a marking behaviour that determines whether a packet should be encoding states are available (PCN-marked and not PCN-marked), as in
PCN-marked with a second encoding. [I-D.moncaster-pcn-baseline-encoding]. Another option in this
circumstance is to trigger both admission control and flow
termination from the single type of PCN-marking; the main downside is
that admission control is less accurate.
o Threshold-marking: a PCN-marking behaviour such that all PCN- Within the PCN-domain there is some flexibility about where the
traffic is marked if the PCN-traffic exceeds a particular rate decision making functionality is located. For admission control, the
(either the PCN-lower-rate or PCN-upper-rate). NOTE: The most natural place is the PCN-ingress-node. For flow termination,
definition reflects the overall intent rather than its whether the PCN-ingress-node or PCN-egress-node is more natural
instantaneous behaviour, since the rate measured at a particular depends on the mechanism used to convert packet markings into a flow
moment depends on the behaviour, its implementation and the termination decision. These possibilities are outlined more later
traffic's variance as well as its rate. and also discussed elsewhere, such as in [Menth08]. Another
possibility is that the decision making functionality is at some
central control node. This is briefly discussed in Appendix A and
described in [I-D.tsou-pcn-racf-applic].
o Excess-rate-marking: a PCN-marking behaviour such that the amount The flow admission and termination decisions need to be enforced
of PCN-traffic that is PCN-marked is equal to the amount that through per-flow policing by the PCN-ingress-nodes. If there are
exceeds a particular rate (either the PCN-lower-rate or PCN-upper- several PCN-domains on the end-to-end path then each needs to police
rate). NOTE: The definition reflects the overall intent rather at its PCN-ingress-nodes. One exception is if the operator runs both
than its instantaneous behaviour, since the rate measured at a the access network (not a PCN-domain) and the core network (a PCN-
particular moment depends on the behaviour, its implementation and domain); per flow policing could be devolved to the access network
the traffic's variance as well as its rate. 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.
o Pre-congestion: a condition of a link within a PCN-domain in which PCN admission control has to fit with the overall approach to
the PCN-node performs PCN-marking, in order to provide an "early admission control. For instance [I-D.briscoe-tsvwg-cl-architecture]
warning" of potential congestion before there is any significant describes the case where RSVP signalling runs end-to-end. The PCN-
build-up of PCN-packets in the real queue. (Hence, by analogy domain is a single RSVP hop, ie only the PCN-boundary-nodes process
with ECN we call our mechanism Pre-Congestion Notification.) RSVP messages, with RSVP messages processed on each hop outside the
PCN-domain, as in IntServ over DiffServ [RFC2998]. 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 is used instead of RSVP.
o PCN-marking: the process of setting the header in a PCN-packet It is possible that a user wants its inelastic traffic to use the PCN
based on defined rules, in reaction to pre-congestion. mechanisms but also react to ECN marking outside the PCN-domain
[I-D.sarker-pcn-ecn-pcn-usecases]. Two ways to do this are to tunnel
all PCN-packets across the PCN-domain, so that the ECN marks is
carried transparently across the PCN-domain, or to use the three
state PCN encoding [I-D.moncaster-pcn-3-state-encoding]. This is
discussed further in Section Section 7.
o PCN-feedback-information: information signalled by a PCN-egress- Some possible deployment models that are outside the current PCN WG
node to a PCN-ingress-node or central control node, which is Charter are outlined in Appendix A.
needed for the flow admission and flow termination mechanisms.
3. Assumptions and constraints on scope 5. Assumptions and constraints on scope
The scope of PCN is, at least initially (see Appendix A), restricted The scope of PCN is, at least initially (see Appendix A), restricted
by the following assumptions: by the following assumptions:
1. these components are deployed in a single DiffServ domain, within 1. these components are deployed in a single DiffServ domain, within
which all PCN-nodes are PCN-enabled and trust each other for which all PCN-nodes are PCN-enabled and trust each other for
truthful PCN-marking and transport truthful PCN-marking and transport
2. all flows handled by these mechanisms are inelastic and 2. all flows handled by these mechanisms are inelastic and
constrained to a known peak rate through policing or shaping constrained to a known peak rate through policing or shaping
skipping to change at page 9, line 38 skipping to change at page 11, line 9
effective. To put it another way, the aggregate bit rate of PCN- effective. To put it another way, the aggregate bit rate of PCN-
traffic across any potential bottleneck link needs to be traffic across any potential bottleneck link needs to be
sufficiently large relative to the maximum additional bit rate sufficiently large relative to the maximum additional bit rate
added by one flow. This is the basic assumption of measurement- added by one flow. This is the basic assumption of measurement-
based admission control. based admission control.
4. PCN-flows may have different precedence, but the applicability of 4. PCN-flows may have different precedence, but the applicability of
the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.)
is out of scope. is out of scope.
3.1. Assumption 1: Trust and support of PCN - controlled environment 5.1. Assumption 1: Trust and support of PCN - controlled environment
We assume that the PCN-domain is a controlled environment, i.e. all We assume that the PCN-domain is a controlled environment, ie all the
the nodes in a PCN-domain run PCN and trust each other. There are nodes in a PCN-domain run PCN and trust each other. There are
several reasons for proposing this assumption: several reasons for proposing this assumption:
o The PCN-domain has to be encircled by a ring of PCN-boundary- o The PCN-domain has to be encircled by a ring of PCN-boundary-
nodes, otherwise traffic could enter a PCN BA without being nodes, otherwise traffic could enter a PCN BA without being
subject to admission control, which would potentially degrade the subject to admission control, which would potentially degrade the
QoS of existing PCN-flows. QoS of existing PCN-flows.
o Similarly, a PCN-boundary-node has to trust that all the PCN-nodes o Similarly, a PCN-boundary-node has to trust that all the PCN-nodes
mark PCN-traffic consistently. A node not doing PCN-marking mark PCN-traffic consistently. A node not doing PCN-marking
wouldn't be able to alert when it suffered pre-congestion, which wouldn't be able to alert when it suffered pre-congestion, which
skipping to change at page 10, line 21 skipping to change at page 11, line 39
domain is run by a single operator. Another possibility is that domain is run by a single operator. Another possibility is that
there are several operators but they trust each other to a sufficient there are several operators but they trust each other to a sufficient
level, in their handling of PCN-traffic. level, in their handling of PCN-traffic.
Note: All PCN-nodes need to be trustworthy. However if it's known Note: All PCN-nodes need to be trustworthy. However if it's known
that an interface cannot become pre-congested then it's not strictly that an interface cannot become pre-congested then it's not strictly
necessary for it to be capable of PCN-marking. But this must be necessary for it to be capable of PCN-marking. But this must be
known even in unusual circumstances, eg after the failure of some known even in unusual circumstances, eg after the failure of some
links. links.
3.2. Assumption 2: Real-time applications 5.2. Assumption 2: Real-time applications
We assume that any variation of source bit rate is independent of the 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 level of pre-congestion. We assume that PCN-packets come from real
time applications generating inelastic traffic [Shenker] like voice time applications generating inelastic traffic, ie it sends packets
and video requiring low delay, jitter and packet loss, for example at the rate the codec produces them, regardless of the availability
the Controlled Load Service, [RFC2211], and the Telephony service of capacity [RFC4594]. For example, voice and video requiring low
class, [RFC4594]. This assumption is to help focus the effort where delay, jitter and packet loss, the Controlled Load Service,
it looks like PCN would be most useful, ie the sorts of applications [RFC2211], and the Telephony service class, [RFC4594]. This
where per flow QoS is a known requirement. In other words we focus assumption is to help focus the effort where it looks like PCN would
on PCN providing a benefit to inelastic traffic (PCN may or may not be most useful, ie the sorts of applications where per flow QoS is a
provide a benefit to other types of traffic). For instance, the known requirement. In other words we focus on PCN providing a
impact of this assumption would be to guide simulations work. benefit to inelastic traffic (PCN may or may not provide a benefit to
other types of traffic). For instance, the impact of this assumption
would be to guide simulations work.
3.3. Assumption 3: Many flows and additional load As a consequence, it is assumed that PCN-marking is being applied to
traffic scheduled with the expedited forwarding per-hop behaviour,
[RFC3246], or traffic with similar characteristics.
5.3. Assumption 3: Many flows and additional load
We assume that there are many PCN-flows on any bottleneck link in the 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- PCN-domain (or, to put it another way, the aggregate bit rate of PCN-
traffic across any potential bottleneck link is sufficiently large traffic across any potential bottleneck link is sufficiently large
relative to the maximum additional bit rate added by one PCN-flow). relative to the maximum additional bit rate added by one PCN-flow).
Measurement-based admission control assumes that the present is a Measurement-based admission control assumes that the present is a
reasonable prediction of the future: the network conditions are reasonable prediction of the future: the network conditions are
measured at the time of a new flow request, however the actual measured at the time of a new flow request, however the actual
network performance must be OK during the call some time later. One network performance must be OK during the call some time later. One
issue is that if there are only a few variable rate flows, then the issue is that if there are only a few variable rate flows, then the
skipping to change at page 11, line 12 skipping to change at page 12, line 35
flow's rate, the total rate of PCN-traffic, and the size of the flow's rate, the total rate of PCN-traffic, and the size of the
"safety margin" between the traffic level at which we start "safety margin" between the traffic level at which we start
admission-marking and at which packets are dropped or significantly admission-marking and at which packets are dropped or significantly
delayed. delayed.
We do not make explicit assumptions on how many PCN-flows are in each We do not make explicit assumptions on how many PCN-flows are in each
ingress-egress-aggregate. Performance evaluation work may clarify ingress-egress-aggregate. Performance evaluation work may clarify
whether it is necessary to make any additional assumption on whether it is necessary to make any additional assumption on
aggregation at the ingress-egress-aggregate level. aggregation at the ingress-egress-aggregate level.
3.4. Assumption 4: Emergency use out of scope 5.4. Assumption 4: Emergency use out of scope
PCN-flows may have different precedence, but the applicability of the PCN-flows may have different precedence, but the applicability of the
PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc) is out PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc) is out
of scope for consideration by the PCN WG. of scope for consideration by the PCN WG.
3.5. Other assumptions 6. High-level functional architecture
As a consequence of Assumption 2 above, it is assumed that PCN-
marking is being applied to traffic scheduled with the expedited
forwarding per-hop behaviour, [RFC3246], or traffic with similar
characteristics.
The following two assumptions apply if the PCN WG decides to encode
PCN-marking in the ECN-field.
o It is assumed that PCN-nodes do not perform ECN, [RFC3168], on
PCN-packets.
o What to do if a packet that is part of a PCN-flow arrives at a
PCN-ingress-node with its CE (Congestion experienced) codepoint
set (or if it detects that the ECN-nonce in use). There are
several possibilities (not discussed further in this document)
about what the PCN-ingress-node should do:
* drop the packet
* downgrade the packet to non PCN-BA, eg best effort
* tunnel the packet, so that the ECN-marking is carried
transparently across the PCN-domain.
4. High-level functional architecture
The high-level approach is to split functionality between: The high-level approach is to split functionality between:
o PCN-interior-nodes 'inside' the PCN-domain, which monitor their o PCN-interior-nodes 'inside' the PCN-domain, which monitor their
own state of pre-congestion on each outgoing interface and mark own state of pre-congestion and mark PCN-packets if appropriate.
PCN-packets if appropriate. They are not flow-aware, nor aware of They are not flow-aware, nor aware of ingress-egress-aggregates.
ingress-egress-aggregates. The functionality is also done by PCN- The functionality is also done by PCN-ingress-nodes for their
ingress-nodes for their outgoing interfaces (ie those 'inside' the outgoing interfaces (ie those 'inside' the PCN-domain).
PCN-domain).
o PCN-boundary-nodes at the edge of the PCN-domain, which control o PCN-boundary-nodes at the edge of the PCN-domain, which control
admission of new PCN-flows and termination of existing PCN-flows, admission of new PCN-flows and termination of existing PCN-flows,
based on information from PCN-interior-nodes. This information is based on information from PCN-interior-nodes. This information is
in the form of the PCN-marked data packets (which are intercepted in the form of the PCN-marked data packets (which are intercepted
by the PCN-egress-nodes) and not signalling messages. Generally by the PCN-egress-nodes) and not signalling messages. Generally
PCN-ingress-nodes are flow-aware. PCN-ingress-nodes are flow-aware.
The aim of this split is to keep the bulk of the network simple, The aim of this split is to keep the bulk of the network simple,
scalable and robust, whilst confining policy, application-level and scalable and robust, whilst confining policy, application-level and
security interactions to the edge of the PCN-domain. For example the 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 lack of flow awareness means that the PCN-interior-nodes don't care
about the flow information associated with the PCN-packets that they about the flow information associated with the PCN-packets that they
carry, nor do the PCN-boundary-nodes care about which PCN-interior- carry, nor do the PCN-boundary-nodes care about which PCN-interior-
nodes its flows traverse. nodes its flows traverse. The objective is to standardise PCN-
marking behaviour, but potentially produce more than one
(informational) RFC describing how PCN-boundary-nodes react to PCN-
marks.
The objective is to standardise PCN-marking behaviour, but In order to generate information about the current state of the PCN-
potentially produce more than one (informational) RFC describing how domain, each PCN-node PCN-marks packets if it is "pre-congested".
PCN-boundary-nodes react to PCN-marks. Exactly when a PCN-node decides if it is "pre-congested" (the
algorithm) and exactly how packets are "PCN-marked" (the encoding)
are defined in separate standards-track documents, but at a high
level it is as follows:
Note: Section 4 and Section 5 talk about PCN functionality being o the algorithms: a PCN-node meters the amount of PCN-traffic on
configured on outgoing interfaces of PCN-nodes. Alternatively, PCN each one of its outgoing (or incoming) links. The measurement is
functionality could be configured on the ingress interfaces of PCN- made as an aggregate of all PCN-packets, and not per flow. There
nodes, however a consistent choice must be made across the PCN-domain are two algorithms, one for threshold-marking and one for excess-
to ensure that the PCN mechanisms protect all links. This document traffic-marking.
assumes configuration on the egress interfaces, because in DiffServ
networks today DiffServ functionality is usually implemented on
egress interfaces.
4.1. Flow admission o the encoding(s): a PCN-node PCN-marks a PCN-packet by setting the
ECN field to 11 and potentially altering the DSCP.
At a high level, flow admission control works as follows. In order The PCN-boundary-nodes monitor the PCN-marked packets in order to
to generate information about the current state of the PCN-domain, extract information about the current state of the PCN-domain. Based
each PCN-node PCN-marks packets if it is "pre-congested". Exactly on this monitoring, a decision is made about whether to admit a
how a PCN-node decides if it is "pre-congested" (the algorithm) and prospective new flow or whether to terminate existing flow(s).
exactly how packets are "PCN-marked" (the encoding) will be defined
in a separate standards-track document, but at a high level it is
expected to be as follows:
o the algorithm: a PCN-node meters the amount of PCN-traffic on each PCN-marking needs to be configured on all links in the PCN-domain to
one of its outgoing links. The measurement is made as an ensure that the PCN mechanisms protect all links. The actual
aggregate of all PCN-packets, and not per flow. The algorithm has functionality can be configured on the outgoing or incoming
a configured parameter, PCN-lower-rate. As the amount of PCN- interfaces of PCN-nodes - or one algorithm could be configured on the
traffic exceeds the PCN-lower-rate, then PCN-packets are PCN- outgoing interface and the other on the incoming interface. The
marked. See NOTE below for more explanation. important thing is that a consistent choice is made across the PCN-
domain to ensure that the PCN mechanisms protect all links. See
[I-D.eardley-pcn-marking-behaviour] for further discussion.
o the encoding: a PCN-node PCN-marks a PCN-packet (with a first The objective of the threshold-marking algorithm is to threshold-mark
encoding) by setting fields in the header to specific values. It all PCN-packets whenever the rate of PCN-packets is greater than some
is expected that the ECN and/or DSCP fields will be used. 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
[I-D.eardley-pcn-marking-behaviour].
NOTE: Two main categories of algorithm have been proposed: if the In a PCN-domain the operator may have two or three encoding states
algorithm uses threshold-marking then all PCN-packets are marked if available. In both cases the ECN field is set to 11 to indicate PCN-
the current rate exceeds the PCN-lower-rate, whereas if the algorithm marking. In the former case, one DSCP is used. In the latter case a
uses excess-rate-marking the amount marked is equal to the amount in second DSCP is used, which allows distinct threshold-marks and
excess of the PCN-lower-rate. However, note that this description excess-traffic-marks. The encoding is specified in
reflects the overall intent of the algorithm rather than its [I-D.moncaster-pcn-baseline-encoding] and
instantaneous behaviour, since the rate measured at a particular [I-D.moncaster-pcn-3-state-encoding].
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 PCN-boundary-nodes monitor the PCN-marked packets in order to All the various admission and termination approaches are detailed and
extract information about the current state of the PCN-domain. Based compared in [I-D.charny-pcn-comparison] and [Menth08]. The
on this monitoring, a decision is made about whether to admit a discussion below is just a brief summary. It initially assumes there
prospective new flow. Exactly how the admission control decision is are three encoding states available.
made will be defined separately (at the moment the intention is that
there will be one or more informational-track RFCs), but at a high 6.1. Flow admission
level two approaches have been proposed to date:
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-
threshold-rate, by admitting or blocking prospective new flows, in
order to protect the QoS of existing PCN-flows. The PCN-threshold-
rate is a parameter that can be configured by the operator and will
be 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. At a high level two
approaches are proposed:
o the PCN-egress-node measures (possibly as a moving average) the o the PCN-egress-node measures (possibly as a moving average) the
fraction of the PCN-traffic that is PCN-marked. The fraction is fraction of the PCN-traffic that is threshold-marked. The
measured for a specific ingress-egress-aggregate. If the fraction fraction is measured for a specific ingress-egress-aggregate. If
is below a threshold value then the new flow is admitted. the fraction is below a threshold value then the new flow is
admitted, and if the fraction is above the threshold value then it
is blocked. In [I-D.eardley-pcn-architecture] the fraction is
measured as an EWMA (exponentially weighted moving average) and
termed the "congestion level estimate".
o if the PCN-egress-node receives one (or several) PCN-marked o the PCN-egress-node monitors PCN-traffic and if it receives one
packets, then a new flow is blocked, otherwise it is admitted. (or several) threshold-marked packets, then the new flow is
blocked, otherwise it is admitted. One possibility is to react to
the marking state of an initial flow set-up packet (eg RSVP PATH).
Another is that after one (or several) threshold-marks then all
flows are blocked until after a specific period of no congestion.
Note that the PCN-lower-rate is a parameter that can be configured by Note that the admission control decision is made for a particular
the operator. It will be set lower than the traffic rate at which pair of PCN-boundary-nodes. So it is quite possible for a new flow
the link becomes congested and the node drops packets. 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.
Note also that the admission control decision is made for a 6.2. Flow termination
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.
4.2. Flow termination The objective of PCN's flow termination mechanism is to limit the
PCN-traffic on each link to *roughly* its PCN-excess-rate, by
terminating some existing PCN-flows, in order to protect the QoS of
the remaining PCN-flows. The PCN-excess-rate is a parameter that can
be configured by the operator and may be set lower than the traffic
rate at which the link becomes congested and the node drops packets.
At a high level, flow termination control works as follows. Each Exactly how the flow termination decision is made will be defined
PCN-node PCN-marks packets in a similar fashion to above, with all separately in informational documents. At a high level several
proposals using an excess-rate-marking approach (Section 4.1). An approaches are proposed:
obvious approach is for the algorithm to use a second configured
parameter, PCN-upper-rate, and a second header encoding. However
there is also a proposal to use the same rate and the same encoding.
Several approaches have been proposed to date about how to convert
this information into a flow termination decision; at a high level
these are as follows:
o In one approach the PCN-egress-node measures the rate of unmarked o In one approach the PCN-egress-node measures the rate of PCN-
PCN-traffic (ie not PCN-upper-rate-marked), which is the amount of traffic that is not excess-traffic-marked, which is the amount of
PCN-traffic that can actually be supported. Also the PCN-ingress- PCN-traffic that can actually be supported. Also the PCN-ingress-
node measures the rate of PCN-traffic that is destined for this node measures the rate of PCN-traffic that is destined for this
specific PCN-egress-node, and hence can calculate the excess specific PCN-egress-node, and hence it can calculate the excess
amount that should be terminated. amount that should be terminated.
o Another approach instead measures the rate of PCN-upper-rate- o Another approach instead measures the rate of excess-traffic-
marked traffic and calculates and selects the flows that should be marked traffic and terminates this amount of traffic. This
terminated. terminates more traffic than the previous bullet if some nodes are
dropping PCN-traffic.
o Another approach terminates any PCN-flow with a PCN-upper-rate-
marked packet. Compared with the approaches above, PCN-marking
needs to be done at a reduced rate (every "s" bytes of excess
traffic) otherwise far too much traffic would be terminated.
o Another approach uses only one sort of marking, which is based on o Another approach monitors PCN-packets and terminates any PCN-flow
the PCN-lower-rate, to decide not only whether to admit more PCN- with an excess-traffic-marked packet. Compared with the
flows but also whether any PCN-flows need to be terminated. It approaches above, PCN-marking needs to be done at a reduced rate
assumes that the ratio of the (implicit) PCN-upper-rate and the (every "s" bytes of excess traffic) otherwise far too much traffic
PCN-lower-rate is the same on all links. This approach measures would be terminated.
the rate of unmarked PCN-traffic at a PCN-egress-node. The PCN-
ingress-node uses this measurement to compute the implicit PCN-
upper-rate of the bottleneck link. It then measures the rate of
PCN-traffic that is destined for this specific PCN-egress-node and
hence can calculate the amount that should be terminated.
Since flow termination is designed for "abnormal" circumstances, it Since flow termination is designed for "abnormal" circumstances, it
is quite likely that some PCN-nodes are congested and hence packets is quite likely that some PCN-nodes are congested and hence packets
are being dropped and/or significantly queued. The flow termination are being dropped and/or significantly queued. The flow termination
mechanism must bear this in mind. mechanism must bear this in mind.
Note also that the termination control decision is made for a Note also that the termination control decision is made for a
particular pair of PCN-boundary-nodes. So it is quite possible for particular pair of PCN-boundary-nodes. So it is quite possible for
PCN-flows to be terminated between one pair of PCN-boundary-nodes, PCN-flows to be terminated between one pair of PCN-boundary-nodes,
whilst at the same time none are terminated between a different pair whilst at the same time none are terminated between a different pair
of PCN-boundary-nodes. of PCN-boundary-nodes.
4.3. Flow admission and flow termination 6.3. Flow admission and flow termination when there are only two PCN
encoding states
Although designed to work together, flow admission and flow If a PCN-domain has only two encoding states available (PCN-marked
termination are independent mechanisms, and the use of one does not and not PCN-marked), ie it's using the baseline encoding
require or prevent the use of the other. [I-D.moncaster-pcn-baseline-encoding], then an operator has three
options:
For example, an operator could use just admission control, solving o admission control only: PCN-marking means threshold-marking, ie
heavy congestion (caused by re-routing) by 'just waiting' - as only the threshold-marking algorithm writes PCN-marks. Only PCN
sessions end, existing microflows naturally depart from the system admission control is available.
over time, and the admission control mechanism will prevent admission
of new microflows 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 PCN-flows naturally
depart to relieve the congestion, all PCN-flows as well as lower
priority services will be adversely affected. On the other hand, 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]. 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. The flow termination mechanism could then be
used to counteract such a problem.
A different possibility is to configure only the PCN-lower-rate and o flow termination only: PCN-marking means excess-traffic-marking,
hence only do one type of PCN-marking, but generate admission and ie only the excess-traffic-marking algorithm writes PCN-marks.
flow termination responses from different levels of marking. This is Only PCN termination control is available.
suggested in [I-D.charny-pcn-single-marking] which gives some of the
pros and cons of this approach.
4.4. Information transport o both admission control and flow termination: only the excess-
traffic-marking algorithm writes PCN-marks, however the configured
rate (PCN-excess-rate) is set at the rate the admission control
mechanism needs to limit PCN-traffic to.
[I-D.charny-pcn-single-marking] describes how both admission
control and flow termination can be triggered in this case and
also gives some of the pros and cons of this approach. The main
downside is that admission control is less accurate.
6.4. Information transport
The transport of pre-congestion information from a PCN-node to a PCN- 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- egress-node is through PCN-markings in data packet headers, ie "in-
band": no signalling protocol messaging is needed. However, band": no signalling protocol messaging is needed. Signalling is
signalling is needed to transport PCN-feedback-information between needed to transport PCN-feedback-information between the PCN-
the PCN-boundary-nodes, for example to convey the fraction of PCN- boundary-nodes, for example to convey the fraction of PCN-marked
marked traffic from a PCN-egress-node to the relevant PCN-ingress- traffic from a PCN-egress-node to the relevant PCN-ingress-node.
node. Exactly what information needs to be transported will be Exactly what information needs to be transported will be described in
described in the future PCN WG document(s) about the boundary the future PCN WG document(s) about the boundary mechanisms. The
mechanisms. The signalling could be done by an extension of RSVP or signalling could be done by an extension of RSVP or NSIS, for
NSIS, for instance; protocol work will be done by the relevant WG, instance; protocol work will be done by the relevant WG, but for
but for example [I-D.lefaucheur-rsvp-ecn] describes the extensions example [I-D.lefaucheur-rsvp-ecn] describes the extensions needed for
needed for RSVP. RSVP.
4.5. PCN-traffic 6.5. PCN-traffic
The following are some high-level points about how PCN works: The following are some high-level points about how PCN works:
o There needs to be a way for a PCN-node to distinguish PCN-traffic o There needs to be a way for a PCN-node to distinguish PCN-traffic
from non PCN-traffic. They may be distinguished using the DSCP from other traffic. This is through a combination of the DSCP
field and/or ECN field. field and/or ECN field.
o The PCN mechanisms may be applied to more than one behaviour o The PCN mechanisms may be applied to more than one behaviour
aggregate (which are distinguished by DSCP). aggregate which are distinguished by DSCP. However the current
PCN encodings, [I-D.moncaster-pcn-baseline-encoding] and
[I-D.moncaster-pcn-3-state-encoding], only allow one PCN-BA.
o There may be traffic that is more important than PCN, perhaps a o There may be traffic that is more important than PCN, perhaps a
particular application or an operator's control messages. A PCN- particular application or an operator's control messages. A PCN-
node may dedicate capacity to such traffic or priority schedule it node may dedicate capacity to such traffic or priority schedule it
over PCN. In the latter case its traffic needs to contribute to over PCN. In the latter case its traffic needs to contribute to
the PCN meters. the PCN meters (ie be metered by the threshold-marking and excess-
traffic-marking algorithms).
o There may be other traffic that uses the same DSCP as PCN-traffic
but with the ECN field is 00 (Not ECT), and so not subject to PCN-
marking, nor PCN's admission control and flow termination
mechanisms.. To quote [I-D.moncaster-pcn-baseline-encoding]: "To
conserve DSCPs, DiffServ Codepoints SHOULD be chosen that are
already defined for use with admission controlled traffic, such as
the Voice-Admit codepoint defined in [voice-admit]." Since
scheduling behaviour is coupled with the DSCP only, therefore the
same scheduling and buffer management rules are applied to non-
PCN-traffic and PCN-traffic using the same PCN-enabled DSCP.
There may be no "non-PCN-traffic", but if there is it needs to
contribute to the PCN meters.
o There will be traffic less important than PCN. For instance best o There will be traffic less important than PCN. For instance best
effort or assured forwarding traffic. It will be scheduled at effort or assured forwarding traffic. It will be scheduled at
lower priority than PCN, and use a separate queue or queues. lower priority than PCN, and use a separate queue or queues.
However, a PCN-node should dedicate some capacity to lower However, a PCN-node should dedicate some capacity to lower
priority traffic so that it isn't starved. priority traffic so that it isn't starved. Such traffic doesn't
contribute to the PCN meters.
o There may be other traffic with the same priority as PCN-traffic. 6.6. Backwards compatibility
For instance, Expedited Forwarding sessions that are originated
either without capacity admission or with traffic engineering. In
[I-D.ietf-tsvwg-admitted-realtime-dscp] the two traffic classes
are called EF and EF-ADMIT. A PCN-node could either use separate
queues, or separate policers and a common queue; the draft
provides some guidance when each is better, but for instance the
latter is preferred when the two traffic classes are carrying the
same type of application with the same jitter requirements.
5. Detailed Functional architecture PCN specifies semantics for the ECN field that differ from the
default semantics of [RFC3168]. BCP124 [RFC4774] gives guidelines
for specifying alternative semantics for the ECN field. These are
discussed in the baseline encoding
[I-D.moncaster-pcn-baseline-encoding] and extended encoding
[I-D.moncaster-pcn-3-state-encoding] documents. In summary, PCN
meets these guidelines by:
o using a DSCP (or two DSCPs in the extended encoding) to allow PCN-
nodes to distinguish PCN-traffic that uses the alternative ECN
semantics;
o defining these semantics for use within a controlled region, the
PCN-domain;
o taking appropriate action if ECN capable, non-PCN traffic arrives
at a PCN-ingress-node with the DSCP used by PCN.
The 'appropriate action' can differ in the case of baseline encoding
and extended encoding. In the former, ECN-capable traffic that uses
the same DSCP as PCN is blocked 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 blocking is needed
is that the PCN-egress-node clears the ECN field to 00. The extended
encoding adds support for end-to-end ECN, since the value of the ECN
field is preserved across the PCN-domain. However, PCN-packets that
get PCN-marked emerge from the PCN-domain with the ECN field set to
11 (CE). It may make sense to expose such marks to a rate adaptive
endpoint. However, it could violate [RFC4774] if the endpoint
doesn't understand ECN, and therefore the PCN-domain first needs to
ensure that the end-to-end transport is ECN capable (probably through
signalling).
7. Detailed Functional architecture
This section is intended to provide a systematic summary of the new This section is intended to provide a systematic summary of the new
functional architecture in the PCN-domain. First it describes functional architecture in the PCN-domain. First it describes
functions needed at the three specific types of PCN-node; these are functions needed at the three specific types of PCN-node; these are
data plane functions and are in addition to their normal router data plane functions and are in addition to their normal router
functions. Then it describes further functionality needed for both functions. Then it describes further functionality needed for both
flow admission control and flow termination; these are signalling and flow admission control and flow termination; these are signalling and
decision-making functions, and there are various possibilities for decision-making functions, and there are various possibilities for
where the functions are physically located. The section is split where the functions are physically located. The section is split
into: into:
skipping to change at page 16, line 47 skipping to change at page 19, line 4
flow admission control and flow termination; these are signalling and flow admission control and flow termination; these are signalling and
decision-making functions, and there are various possibilities for decision-making functions, and there are various possibilities for
where the functions are physically located. The section is split where the functions are physically located. The section is split
into: into:
1. functions needed at PCN-interior-nodes 1. functions needed at PCN-interior-nodes
2. functions needed at PCN-ingress-nodes 2. functions needed at PCN-ingress-nodes
3. functions needed at PCN-egress-nodes 3. functions needed at PCN-egress-nodes
4. other functions needed for flow admission control 4. other functions needed for flow admission control
5. other functions needed for flow termination control 5. other functions needed for flow termination control
Note: Probing is covered in Section 7.
Note: Probing is covered in Appendix B.
The section then discusses some other detailed topics: The section then discusses some other detailed topics:
1. addressing 1. addressing
2. tunnelling 2. tunnelling
3. fault handling 3. fault handling
5.1. PCN-interior-node functions 7.1. PCN-interior-node functions
Each interface of the PCN-domain is configured with the following Each link of the PCN-domain is configured with the following
functionality: functionality:
o Packet classify - decide whether an incoming packet is a PCN- o Packet classify - decide whether an incoming packet is a PCN-
packet or not. Another PCN WG document will specify encoding, packet or not.
using the DSCP and/or ECN fields.
o PCN-meter - measure the 'amount of PCN-traffic'. The measurement o Packet condition - if the level if traffic is sufficiently high to
is made as an aggregate of all PCN-packets, and not per flow. overload the PCN_BA, ie cause real congestion, then drop or
downgrade PCN-packets.
o PCN-mark - algorithms determine whether to PCN-mark PCN-packets o Meter - measure the 'amount of PCN-traffic'. The measurement is
and what packet encoding is used (as specified in another PCN WG made as an aggregate of all PCN-packets, and not per flow.
document).
The same general approach of metering and PCN-marking is performed o Mark - algorithms determine whether to PCN-mark PCN-packets and
for both flow admission control and flow termination, however the what packet encoding is used.
algorithms and encoding may be different.
These functions are needed for each interface of the PCN-domain. The functions are specified in [I-D.eardley-pcn-marking-behaviour]
They are therefore needed on all interfaces of PCN-interior-nodes, and the encodings in [I-D.moncaster-pcn-baseline-encoding] and
and on the interfaces of PCN-boundary-nodes that are internal to the [I-D.moncaster-pcn-3-state-encoding].
PCN-domain. There may be more than one PCN-meter and marker
installed at a given interface, eg one for admission and one for
termination.
5.2. PCN-ingress-node functions 7.2. PCN-ingress-node functions
Each ingress interface of the PCN-domain is configured with the Each ingress link of the PCN-domain is configured with the following
following functionality: functionality:
o Packet classify - decide whether an incoming packet is part of a o Packet classify - decide whether an incoming packet is part of a
previously admitted microflow, by using a filter spec (eg DSCP, previously admitted flow, by using a filter spec (eg DSCP, source
source and destination addresses and port numbers) and destination addresses and port numbers).
o Police - police, by dropping or re-marking with a non-PCN DSCP, o Police - police, by dropping or downgrading, any packets received
any packets received with a DSCP demanding PCN transport that do with a DSCP demanding PCN transport that do not belong to an
not belong to an admitted flow. Similarly, police packets that admitted flow. Similarly, police packets that are part of a
are part of a previously admitted microflow, to check that the previously admitted flow, to check that the flow keeps to the
microflow keeps to the agreed rate or flowspec (eg RFC1633 agreed rate or flowspec (eg RFC1633 [RFC1633] for a microflow and
[RFC1633] and NSIS equivalent). There is a need to be careful to its NSIS equivalent).
avoid re-ordering traffic.
o PCN-colour - set the DSCP field or DSCP and ECN fields to the o Packet colour - set the DSCP and ECN fields appropriately, see
appropriate value(s) for a PCN-packet. The draft about PCN- [I-D.moncaster-pcn-baseline-encoding] or
encoding will discuss further. [I-D.moncaster-pcn-3-state-encoding] as appropriate for the PCN-
domain.
o PCN-meter - make "measurements of PCN-traffic". Some approaches o Meter - some approaches to flow termination require the PCN-
to flow termination require the PCN-ingress-node to measure the ingress-node to measure the (aggregate) rate of PCN-traffic
(aggregate) rate of PCN-traffic towards a particular PCN-egress- towards a particular PCN-egress-node.
node.
The first two are policing functions, needed to make sure that PCN- The first two are policing functions, needed to make sure that PCN-
packets admitted into the PCN-domain belong to a flow that's been packets admitted into the PCN-domain belong to a flow that's been
admitted and to ensure that the flow keeps to the flowspec agreed (eg admitted and to ensure that the flow keeps to the flowspec agreed (eg
doesn't go at a faster rate and is inelastic traffic). Installing doesn't go at a faster rate and is inelastic traffic). Installing
the filter spec will typically be done by the signalling protocol, as the filter spec will typically be done by the signalling protocol, as
will re-installing the filter, for example after a re-route that will re-installing the filter, for example after a re-route that
changes the PCN-ingress-node (see [I-D.briscoe-tsvwg-cl-architecture] changes the PCN-ingress-node (see [I-D.briscoe-tsvwg-cl-architecture]
for an example using RSVP). PCN-colouring allows the rest of the for an example using RSVP). Packet colouring allows the rest of the
PCN-domain to recognise PCN-packets. PCN-domain to recognise PCN-packets.
5.3. PCN-egress-node functions 7.3. PCN-egress-node functions
Each egress interface of the PCN-domain is configured with the Each egress link of the PCN-domain is configured with the following
following functionality: functionality:
o Packet classify - determine which PCN-ingress-node a PCN-packet o Packet classify - determine which PCN-ingress-node a PCN-packet
has come from. has come from.
o PCN-meter - "measure PCN-traffic" or "monitor PCN-marks". o Meter - "measure PCN-traffic" or "monitor PCN-marks".
o PCN-colour - for PCN-packets, set the DSCP and ECN fields to the o Packet colour - for PCN-packets, set the DSCP and ECN fields to
appropriate values for use outside the PCN-domain. the appropriate values for use outside the PCN-domain.
Another PCN WG document, about boundary mechanisms, will describe The metering functionality of course depends on whether it is
PCN-metering in more detail. As described in Section 4.1 and Section targeted at admission control or flow termination. Alternative
4.2, at present there are two alternative proposals: to measure as an proposals involve the PCN-egress-node "measuring" as an aggregate (ie
aggregate (ie not per flow) all PCN-packets from a particular PCN- not per flow) all PCN-packets from a particular PCN-ingress-node, or
ingress-node; or to monitor the PCN-traffic and react to one (or "monitoring" the PCN-traffic and reacting to one (or several) PCN-
several) PCN-marks. We refer to these approaches as "measuring PCN- marked packets.
traffic" and "monitoring PCN-marks". The PCN-metering functionality
also depends on whether the measurement is targeted at admission
control or flow termination. It also depends on what encoding and
PCN-marking algorithms are specified by the PCN WG.
5.4. Other admission control functions 7.4. Other admission control functions
As well as the functions covered above (Sections 5.1, 5.2, 5.3), As well as the functions covered above, other specific admission
other specific admission control functions can be performed at a PCN- control functions can be performed at a PCN-boundary-node (PCN-
boundary-node (PCN-ingress-node or PCN-egress-node) or at a ingress-node or PCN-egress-node) or at a centralised node, but not at
centralised node, but not at normal PCN-interior-nodes. The normal PCN-interior-nodes. The functions are:
functions are:
o Make decision about admission - based on the output of the PCN- o Make decision about admission - based on the output of the PCN-
egress-node's PCN-meter function. In the case where it "measures egress-node's PCN meter function. In the case where it "measures
PCN-traffic", the measured traffic on the ingress-egress-aggregate PCN-traffic", the measured traffic on the ingress-egress-aggregate
is compared with some reference level. In the case where it is compared with some reference level. In the case where it
"monitors PCN-marks", then the decision is based on whether one "monitors PCN-marks", then the decision is based on whether one
(or several) packets is (are) PCN-marked or not. In either case, (or several) packets is (are) PCN-marked or not. In either case,
the admission decision also takes account of policy and the admission decision also takes account of policy and
application layer requirements. application layer requirements.
o Communicate decision about admission - signal the decision to the o Communicate decision about admission - signal the decision to the
node making the admission control request (which may be outside node making the admission control request (which may be outside
the PCN-domain), and to the policer (PCN-ingress-node function) the PCN-domain), and to the policer (PCN-ingress-node function)
for enforcement of the decision. for enforcement of the decision.
There are various possibilities for how the functionality can be There are various possibilities for how the functionality can be
distributed (we assume the operator would configure which is used): distributed (we assume the operator would configure which is used):
o The decision is made at the PCN-egress-node and signalled to the o The decision is made at the PCN-egress-node and the decision
PCN-ingress-node (admit or block) is signalled to the PCN-ingress-node. This seems
most natural.
o The decision is made at the PCN-ingress-node, which requires that o The decision is made at the PCN-ingress-node, which requires that
the PCN-egress-node signals PCN-feedback-information to the PCN- the PCN-egress-node signals PCN-feedback-information to the PCN-
ingress-node. For example, in the case where the PCN-meter ingress-node. For example, it could signal the current fraction
function is to "measure PCN-traffic" it could signal the fraction
of PCN-traffic that is PCN-marked. of PCN-traffic that is PCN-marked.
o The decision is made at a centralised node (see Appendix). o The decision is made at a centralised node (see Appendix A).
The decision needs to be passed to the application layer so that it
can take the appropriate action.
5.5. Other flow termination functions 7.5. Other flow termination functions
Specific termination control functions can be performed at a PCN- Specific termination control functions can be performed at a PCN-
boundary-node (PCN-ingress-node or PCN-egress-node) or at a boundary-node (PCN-ingress-node or PCN-egress-node) or at a
centralised node, but not at normal PCN-interior-nodes. There are centralised node, but not at normal PCN-interior-nodes. There are
various possibilities for how the functionality can be distributed, various possibilities for how the functionality can be distributed,
similar to those discussed above in the Admission control section; similar to those discussed above in the Admission control section;
the flow termination decision could be made at the PCN-ingress-node, the flow termination decision could be made at the PCN-ingress-node,
the PCN-egress-node or at some centralised node. The functions are: the PCN-egress-node or at some centralised node. The functions are:
o PCN-meter at PCN-egress-node - similarly to flow admission, there o PCN-meter at PCN-egress-node - similarly to flow admission, there
are two proposals: to "measure PCN-traffic" on the ingress-egress- are two types of proposals: to "measure PCN-traffic" on the
aggregate, and to "monitor PCN-marks" and react to one (or ingress-egress-aggregate, and to "monitor PCN-marks" and react to
several) PCN-marks. one (or several) PCN-marks.
o (if required) PCN-meter at PCN-ingress-node - make "measurements o (if required) PCN-meter at PCN-ingress-node - make "measurements
of PCN-traffic" being sent towards a particular PCN-egress-node; of PCN-traffic" being sent towards a particular PCN-egress-node;
again, this is done for the ingress-egress-aggregate and not per again, this is done for the ingress-egress-aggregate and not per
flow. flow.
o (if required) Communicate PCN-feedback-information to the node o (if required) Communicate PCN-feedback-information to the node
that makes the flow termination decision. For example, as in that makes the flow termination decision. For example, as in
[I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress- [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress-
node's measurements to the PCN-ingress-node. node's measurements to the PCN-ingress-node.
skipping to change at page 20, line 30 skipping to change at page 22, line 21
o Make decision about flow termination - use the information from o Make decision about flow termination - use the information from
the PCN-meter(s) to decide which PCN-flow or PCN-flows to the PCN-meter(s) to decide which PCN-flow or PCN-flows to
terminate. The decision takes account of policy and application terminate. The decision takes account of policy and application
layer requirements. layer requirements.
o Communicate decision about flow termination - signal the decision o Communicate decision about flow termination - signal the decision
to the node that is able to terminate the flow (which may be to the node that is able to terminate the flow (which may be
outside the PCN-domain), and to the policer (PCN-ingress-node outside the PCN-domain), and to the policer (PCN-ingress-node
function) for enforcement of the decision. function) for enforcement of the decision.
5.6. Addressing 7.6. Addressing
PCN-nodes may need to know the address of other PCN-nodes. Note: in 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 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 other PCN-nodes (except as normal their next hop neighbours, for
routing purposes). routing purposes).
The PCN-egress-node needs to know the address of the PCN-ingress-node 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 associated with a flow, at a minimum so that the PCN-ingress-node can
be informed to enforce the admission decision (and any flow be informed to enforce the admission decision (and any flow
termination decision) through policing. There are various termination decision) through policing. There are various
possibilities for how the PCN-egress-node can do this, ie associate possibilities for how the PCN-egress-node can do this, ie associate
the received packet to the correct ingress-egress-aggregate. It is the received packet to the correct ingress-egress-aggregate. It is
not the intention of this document to mandate a particular mechanism. not the intention of this document to mandate a particular mechanism.
o The addressing information can be gathered from signalling. For o The addressing information can be gathered from signalling. For
example, regular processing of an RSVP Path message, as the PCN- example, regular processing of an RSVP Path message, as the PCN-
ingress-node is the previous RSVP hop (PHOP) ingress-node is the previous RSVP hop (PHOP)
([I-D.lefaucheur-rsvp-ecn]). ([I-D.lefaucheur-rsvp-ecn]). Or the PCN-ingress-node could signal
its address to the PCN-egress-node.
o Use a probe packet that includes as payload the address of the
PCN-ingress-node.
o Always tunnel PCN-traffic across the PCN-domain. Then the PCN- o Always tunnel PCN-traffic across the PCN-domain. Then the PCN-
ingress-node's address is simply the source address of the outer ingress-node's address is simply the source address of the outer
packet header. The PCN-ingress-node needs to learn the address of packet header. The PCN-ingress-node needs to learn the address of
the PCN-egress-node, either by manual configuration or by one of the PCN-egress-node, either by manual configuration or by one of
the automated tunnel endpoint discovery mechanisms (such as the automated tunnel endpoint discovery mechanisms (such as
signalling or probing over the data route, interrogating routing signalling or probing over the data route, interrogating routing
or using a centralised broker). or using a centralised broker).
5.7. Tunnelling 7.7. Tunnelling
Tunnels may originate and/or terminate within a PCN-domain. It is Tunnels may originate and/or terminate within a PCN-domain. It is
important that the PCN-marking of any packet can potentially important that the PCN-marking of any packet can potentially
influence PCN's flow admission control and termination - it shouldn't influence PCN's flow admission control and termination - it shouldn't
matter whether the packet happens to be tunnelled at the PCN-node matter whether the packet happens to be tunnelled at the PCN-node
that PCN-marks the packet, or indeed whether it's decapsulated or that PCN-marks the packet, or indeed whether it's decapsulated or
encapsulated by a subsequent PCN-node. This suggests that the encapsulated by a subsequent PCN-node. This suggests that the
"uniform conceptual model" described in [RFC2983] should be re- "uniform conceptual model" described in [RFC2983] should be re-
applied in the PCN context. In line with this and the approach of applied in the PCN context. In line with this and the approach of
[RFC4303] and [I-D.briscoe-tsvwg-ecn-tunnel], the following rule is [RFC4303] and [I-D.briscoe-tsvwg-ecn-tunnel], the following rule is
skipping to change at page 21, line 35 skipping to change at page 23, line 27
o any PCN-marking is copied into the outer header o any PCN-marking is copied into the outer header
Similarly, in line with the "uniform conceptual model" of [RFC2983] Similarly, in line with the "uniform conceptual model" of [RFC2983]
and the "full-functionality option" of [RFC3168], the following rule and the "full-functionality option" of [RFC3168], the following rule
is applied if decapsulation is done within the PCN-domain: is applied if decapsulation is done within the PCN-domain:
o if the outer header's marking state is more severe then it is o if the outer header's marking state is more severe then it is
copied onto the inner header copied onto the inner header
o Note: the order of increasing severity is: unmarked; PCN-marking o Note: the order of increasing severity is: not PCN-marked;
with first encoding (ie associated with the PCN-lower-rate); PCN- threshold-marking; excess-traffic-marking.
marking with second encoding (ie associated with the PCN-upper-
rate)
An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to 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-egress-nodes. The PCN-marks shouldn't be visible outside the
PCN-domain, which can be achieved by doing the PCN-colour function PCN-domain, which can be achieved by the PCN-egress-node doing the
(Section 5.3) after all the other (PCN and tunnelling) functions. packet colouring function (Section 7.3) after all the other (PCN and
The potential reasons for doing such tunnelling are: the PCN-egress- tunnelling) functions. The potential reasons for doing such
node then automatically knows the address of the relevant PCN- tunnelling are: the PCN-egress-node then automatically knows the
ingress-node for a flow; even if ECMP is running, all PCN-packets on address of the relevant PCN-ingress-node for a flow; even if ECMP is
a particular ingress-egress-aggregate follow the same path. But it running, all PCN-packets on a particular ingress-egress-aggregate
also has drawbacks, for example the additional overhead in terms of follow the same path. But it also has drawbacks, for example the
bandwidth and processing, and the cost of setting up a mesh of additional overhead in terms of bandwidth and processing, and the
tunnels between PCN-boundary-nodes (there is an N^2 scaling issue). 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 Potential issues arise for a "partially PCN-capable tunnel", ie where
only one tunnel endpoint is in the PCN domain: only one tunnel endpoint is in the PCN domain:
1. The tunnel starts outside a PCN-domain and finishes inside it. 1. The tunnel starts outside a PCN-domain and finishes inside it.
If the packet arrives at the tunnel ingress with the same If the packet arrives at the tunnel ingress with the same
encoding as used within the PCN-domain to indicate PCN-marking, encoding as used within the PCN-domain to indicate PCN-marking,
then this could lead the PCN-egress-node to falsely measure pre- then this could lead the PCN-egress-node to falsely measure pre-
congestion. congestion.
skipping to change at page 22, line 32 skipping to change at page 24, line 25
decapsulation' rule above. decapsulation' rule above.
o For case (2), the tunnel ingress node clears any PCN-marking on o For case (2), the tunnel ingress node clears any PCN-marking on
the inner header. This rule is applied after the 'copy on the inner header. This rule is applied after the 'copy on
encapsulation' rule above. encapsulation' rule above.
Note that the above implies that one has to know, or figure out, the Note that the above implies that one has to know, or figure out, the
characteristics of the other end of the tunnel as part of setting it characteristics of the other end of the tunnel as part of setting it
up. up.
5.8. Fault handling Tunnelling constraints were a major factor in the choice of encoding,
as explained in [I-D.moncaster-pcn-baseline-encoding] and
[I-D.moncaster-pcn-3-state-encoding]. A lengthy discussion of all
the issues associated with layered encapsulation of congestion
notification (for ECN as well as PCN) is in
[I-D.briscoe-tsvwg-ecn-tunnel].
7.8. Fault handling
If a PCN-interior-node fails (or one of its links), then lower layer If a PCN-interior-node fails (or one of its links), then lower layer
protection mechanisms or the regular IP routing protocol will protection mechanisms or the regular IP routing protocol will
eventually re-route round it. If the new route can carry all the eventually re-route round it. If the new route can carry all the
admitted traffic, flows will gracefully continue. If instead this admitted traffic, flows will gracefully continue. If instead this
causes early warning of pre-congestion on the new route, then causes early warning of pre-congestion on the new route, then
admission control based on pre-congestion notification will ensure admission control based on pre-congestion notification will ensure
new flows will not be admitted until enough existing flows have new flows will not be admitted until enough existing flows have
departed. Re-routing may result in heavy (pre-)congestion, when the departed. Re-routing may result in heavy (pre-)congestion, when the
flow termination mechanism will kick in. flow termination mechanism will kick in.
If a PCN-boundary-node fails then we would like the regular QoS If a PCN-boundary-node fails then we would like the regular QoS
signalling protocol to take care of things. As an example signalling protocol to take care of things. As an example
[I-D.briscoe-tsvwg-cl-architecture] considers what happens if RSVP is [I-D.briscoe-tsvwg-cl-architecture] considers what happens if RSVP is
the QoS signalling protocol. the QoS signalling protocol.
6. Design goals and challenges 8. Design goals and challenges
Prior work on PCN and similar mechanisms has thrown up a number of Prior work on PCN and similar mechanisms has thrown up a number of
considerations about PCN's design goals (things PCN should be good considerations about PCN's design goals (things PCN should be good
at) and some issues that have been hard to solve in a fully 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- satisfactory manner. Taken as a whole it represents a list of trade-
offs (it's unlikely that they can all be 100% achieved) and perhaps offs (it's unlikely that they can all be 100% achieved) and perhaps
as evaluation criteria to help an operator (or the IETF) decide as evaluation criteria to help an operator (or the IETF) decide
between options. between options.
The following are key design goals for PCN (based on The following are key design goals for PCN (based on
skipping to change at page 23, line 33 skipping to change at page 25, line 29
o Support of different types of real-time traffic (eg should work o Support of different types of real-time traffic (eg should work
well with CBR and VBR voice and video sources treated together) well with CBR and VBR voice and video sources treated together)
o Reaction time of the mechanisms should be commensurate with the o Reaction time of the mechanisms should be commensurate with the
desired application-level requirements (eg a termination mechanism desired application-level requirements (eg a termination mechanism
needs to terminate flows before significant QoS issues are needs to terminate flows before significant QoS issues are
experienced by real-time traffic, and before most users hang up). experienced by real-time traffic, and before most users hang up).
o Compatibility with different precedence levels of real-time o Compatibility with different precedence levels of real-time
applications (e.g. preferential treatment of higher precedence applications (eg preferential treatment of higher precedence calls
calls over lower precedence calls, [ITU-MLPP]. over lower precedence calls, [ITU-MLPP]).
The following are open issues. They are mainly taken from The following are open issues. They are mainly taken from
[I-D.briscoe-tsvwg-cl-architecture] which also describes some [I-D.briscoe-tsvwg-cl-architecture] which also describes some
possible solutions. Note that some may be considered unimportant in possible solutions. Note that some may be considered unimportant in
general or in specific deployment scenarios or by some operators. general or in specific deployment scenarios or by some operators.
NOTE: Potential solutions are out of scope for this document. NOTE: Potential solutions are out of scope for this document.
o ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion o ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion
is measured on a specific ingress-egress-aggregate. However, if is measured on a specific ingress-egress-aggregate. However, if
skipping to change at page 24, line 25 skipping to change at page 26, line 22
Since flow termination is a 'last resort' that protects the Since flow termination is a 'last resort' that protects the
network should over-admission occur, this problem is probably network should over-admission occur, this problem is probably
more important to solve than the other two. more important to solve than the other two.
o ECMP and signalling: It is possible that, in a PCN-domain running o ECMP and signalling: It is possible that, in a PCN-domain running
ECMP, the signalling packets (eg RSVP, NSIS) follow a different ECMP, the signalling packets (eg RSVP, NSIS) follow a different
path than the data packets, which could matter if the signalling path than the data packets, which could matter if the signalling
packets are used as probes. Whether this is an issue depends on packets are used as probes. Whether this is an issue depends on
which fields the ECMP algorithm uses; if the ECMP algorithm is which fields the ECMP algorithm uses; if the ECMP algorithm is
restricted to the source and destination IP addresses, then it restricted to the source and destination IP addresses, then it
won't be. won't be. ECMP and signalling interactions are a specific
instance of a general issue for non-traditional routing combined
with resource management along a path [Hancock].
o Tunnelling: There are scenarios where tunnelling makes it hard to o Tunnelling: There are scenarios where tunnelling makes it hard to
determine the path in the PCN-domain. The problem, its impact and determine the path in the PCN-domain. The problem, its impact and
the potential solutions are similar to those for ECMP. the potential solutions are similar to those for ECMP.
o Scenarios with only one tunnel endpoint in the PCN domain may make o Scenarios with only one tunnel endpoint in the PCN domain may make
it harder for the PCN-egress-node to gather from the signalling it harder for the PCN-egress-node to gather from the signalling
messages (eg RSVP, NSIS) the identity of the PCN-ingress-node. messages (eg RSVP, NSIS) the identity of the PCN-ingress-node.
o Bi-Directional Sessions: Many applications have bi-directional o Bi-Directional Sessions: Many applications have bi-directional
skipping to change at page 25, line 39 skipping to change at page 27, line 38
signalling level, for instance QoS requests should be rate limited signalling level, for instance QoS requests should be rate limited
to bound the number of requests able to arrive within the to bound the number of requests able to arrive within the
vulnerability period. vulnerability period.
o Silent at start: after a successful admission request the source o Silent at start: after a successful admission request the source
may wait some time before sending data (eg waiting for the called may wait some time before sending data (eg waiting for the called
party to answer). Then the risk is that, in some circumstances, party to answer). Then the risk is that, in some circumstances,
PCN's measurements underestimate what the pre-congestion level PCN's measurements underestimate what the pre-congestion level
will be when the source does start sending data. will be when the source does start sending data.
o Compatibility of PCN-encoding with ECN-encoding. This issue will 9. Operations and Management
be considered further in the PCN WG Milestone 'Survey of encoding
choices'.
7. Probing
7.1. Introduction
Probing is an optional 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 the link that's
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-lower-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. Another possibility is that a probe packet is a signalling
packet that is anyway travelling from the PCN-ingress-node to the
PCN-egress-node (eg an RSVP PATH message travelling from source to
destination).
7.2. Probing functions
The probing functions are:
o Make decision that probing is needed. As described above, this is
when the ingress-egress-aggregate (or the ECMP path - Section 6)
carries no PCN-traffic. An alternative is always to probe, ie
probe before admitting every PCN-flow.
o (if required) Communicate the request that probing is needed - the
PCN-egress-node signals to the PCN-ingress-node that probing is
needed
o (if required) Generate probe traffic - the PCN-ingress-node
generates the probe traffic. The appropriate number (or rate) of
probe packets will depend on the PCN-marking algorithm; for
example an excess-rate-marking algorithm generates fewer PCN-marks
than a threshold-marking algorithm, and so will need more probe
packets.
o Forward probe packets - as far as PCN-interior-nodes are
concerned, probe packets must be handled the same as (ordinary
data) PCN-packets, in terms of routing, scheduling and PCN-
marking.
o Consume probe packets - the PCN-egress-node consumes probe packets
to ensure that they don't travel beyond the PCN-domain.
7.3. Discussion of rationale for probing, its downsides and open issues
It is an unresolved question whether probing is really needed, but
three 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. The third viewpoint is that
admission control is always done by probing. We now consider each in
turn.
The first viewpoint assumes the following:
o There is no PCN-traffic on the ingress-egress-aggregate (so a
normal admission decision cannot be made).
o Simply admitting the new flow has a significant risk of leading to
overload: packets dropped or flows terminated.
On the former bullet, [PCN-email-traffic-empty-aggregates] 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 a new flow starts on many of the
empty ingress-egress-aggregates and causes overload on 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,
and also flows naturally end anyway.
The downsides of probing for this viewpoint are:
o Probing adds delay to the admission control process.
o Sufficient probing traffic has to be generated to test the pre-
congestion level of the ingress-egress-aggregate. But the probing
traffic itself may cause pre-congestion, causing other PCN-flows
to be blocked or even terminated - and in the flash crowd scenario
there will be probing on many ingress-egress-aggregates.
The open issues associated with this viewpoint include:
o What rate and pattern of probe packets does the PCN-ingress-node
need to generate, so that there's enough traffic to make the
admission decision?
o What difficulty does the delay (whilst probing is done) cause
applications, eg packets might be dropped?
o Are there other ways of dealing with the flash crowd scenario?
For instance limit the rate at which new flows are admitted; or
perhaps for a PCN-egress-node to block new flows on its empty
ingress-egress-aggregates when its non-empty ones are pre-
congested.
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:
o there's a significant chance that the traffic is unevenly balanced
across the ECMP paths, and hence there's a significant risk of
admitting a flow that should be blocked (because it follows an
ECMP path that is pre-congested) or blocking a flow that should be
admitted.
o Note: [PCN-email-ECMP] suggests unbalanced traffic is quite
possible, even with quite a large number of flows on a PCN-link
(eg 1000) when Assumption 3 (aggregation) is likely to be
satisfied.
(2) If admission control is based on measurements of pre-congestion
on specific ECMP paths, then the viewpoint that probing is useful
assumes:
o There is no PCN-traffic on the ECMP path on which to base an
admission decision.
o Simply admitting the new flow has a significant risk of leading to
overload.
o The PCN-egress-node can match a packet to an ECMP path.
o Note: This is similar to the first viewpoint and so similarly
could occur in a flash crowd if a new flow starts more-or-less
simultaneously on many of the empty ECMP paths. Because there are
several (sometimes many) ECMP paths between each pair of PCN-
boundary-nodes, it's presumably more likely that an ECMP path is
'empty' than an ingress-egress-aggregate. To constrain the number
of ECMP paths, a few tunnels could be set-up between each pair of
PCN-boundary-nodes. Tunnelling also solves the third bullet
(which is otherwise hard because an ECMP routing decision is made
independently on each node).
The downsides of probing for this viewpoint are:
o Probing adds delay to the admission control process.
o Sufficient probing traffic has to be generated to test the pre-
congestion level of the ECMP path. But there's the risk that the
probing traffic itself may cause pre-congestion, causing other
PCN-flows to be blocked or even terminated.
o The PCN-egress-node needs to consume the probe packets to ensure
they don't travel beyond the PCN-domain (eg they might confuse the
destination end node). Hence somehow the PCN-egress-node has to
be able to disambiguate a probe packet from a data packet, via the
characteristic setting of particular bit(s) in the packet's header
or body - but these bit(s) mustn't be used by any PCN-interior-
node's ECMP algorithm. In the general case this isn't possible,
but it should be OK for a typical ECMP algorithm which examines:
the source and destination IP addresses and port numbers, the
protocol ID and the DSCP.
The third viewpoint assumes the following:
o Every admission control decision involves probing, using the
signalling set-up message as the probe packet (eg RSVP PATH).
o The PCN-marking behaviour is such that every packet is PCN-marked
if the flow should be blocked, hence only a single probing packet
is needed.
This viewpoint [I-D.draft-babiarz-pcn-3sm] has in particular been
suggested for the scenario where the PCN-domain reaches out towards
the end terminals (note that it's assumed the trust and aggregation
assumptions still hold), although it has also been suggested for
other scenarios.
8. Operations and Management
This Section considers operations and management issues, under the This Section considers operations and management issues, under the
FCAPS headings: OAM of Faults, Configuration, Accounting, Performance FCAPS headings: OAM of Faults, Configuration, Accounting, Performance
and Security. Provisioning is discussed with performance. and Security. Provisioning is discussed with performance.
8.1. Configuration OAM 9.1. Configuration OAM
This architecture document predates the detailed standards actions of This architecture document predates the detailed standards actions of
the PCN WG. Here we assume that only interoperable PCN-marking the PCN WG. Here we assume that only inter-operable PCN-marking
behaviours will be standardised, otherwise we would have to consider behaviours will be standardised, otherwise we would have to consider
how to avoid interactions between non-interoperable marking how to avoid interactions between non inter-operable marking
behaviours. However, more diversity in PCN-boundary-node behaviours behaviours. However, more diversity in PCN-boundary-node behaviours
is expected, in order to interface with diverse industry is expected, in order to interface with diverse industry
architectures. It may be possible to have different PCN-boundary- architectures. It may be possible to have different PCN-boundary-
node behaviours for different ingress-egress-aggregates within the node behaviours for different ingress-egress-aggregates within the
same PCN-domain. same PCN-domain.
PCN functionality is configured on either the egress or the ingress PCN functionality is configured on either the egress or the ingress
interfaces of PCN-nodes. A consistent choice must be made across the interfaces of PCN-nodes. A consistent choice must be made across the
PCN-domain to ensure that the PCN mechanisms protect all links. PCN-domain to ensure that the PCN mechanisms protect all links.
skipping to change at page 31, line 5 skipping to change at page 28, line 36
Some configuration options and parameters have to be set once to Some configuration options and parameters have to be set once to
'globally' control the whole PCN-domain. Where possible, these are 'globally' control the whole PCN-domain. Where possible, these are
identified below. This may affect operational complexity and the identified below. This may affect operational complexity and the
chances of interoperability problems between kit from different chances of interoperability problems between kit from different
vendors. vendors.
It may be possible for an operator to configure some PCN-interior- It may be possible for an operator to configure some PCN-interior-
nodes so they don't run the PCN mechanisms, if it knows that these nodes so they don't run the PCN mechanisms, if it knows that these
links will never become (pre-)congested. links will never become (pre-)congested.
8.1.1. System options 9.1.1. System options
On PCN-interior-nodes there will be very few system options: On PCN-interior-nodes there will be very few system options:
o Whether two PCN-markings (based on the PCN-lower-rate and PCN- o Whether two PCN-markings (threshold-marked and excess-traffic-
upper-rate) are enabled or only one (see Section 4.3). Typically marked) are enabled or only one. Typically all nodes throughout a
all nodes throughout a PCN-domain will be configured the same in PCN-domain will be configured the same in this respect. However,
this respect. However, exceptions could be made. For example, if exceptions could be made. For example, if most PCN-nodes used
most PCN-nodes used both markings, but some legacy hardware was both markings, but some legacy hardware was incapable of running
incapable of running two algorithms, an operator might be willing two algorithms, an operator might be willing to configure these
to configure these legacy nodes solely for PCN-marking based on legacy nodes solely for excess-traffic-marking to enable flow
the PCN-upper-rate to enable flow termination as a back-stop. It termination as a back-stop. It would be sensible to place such
would be sensible to place such nodes where they could be nodes where they could be provisioned with a greater leeway over
provisioned with a greater leeway over expected traffic levels. expected traffic levels.
o which marking algorithm to use, if an equipment vendor provides a o what marking algorithm to use, if an equipment vendor provides a
choice choice.
PCN-boundary-nodes (ingress and egress) will have more system PCN-boundary-nodes (ingress and egress) will have more system
options: options:
o Which of admission and flow termination are enabled. If any PCN- o Which of admission and flow termination are enabled. If any PCN-
interior-node is configured to generate a marking, all PCN- interior-node is configured to generate a marking, all PCN-
boundary-nodes must be able to handle that marking. Therefore all boundary-nodes must be able to handle that marking. Therefore all
PCN-boundary-nodes must be configured the same in this respect. PCN-boundary-nodes must be configured the same in this respect.
o Where flow admission and termination decisions are made: at the o Where flow admission and termination decisions are made: at the
PCN-ingress-node, PCN-egress-node or at a centralised node (see PCN-ingress-node, PCN-egress-node or at a centralised node (see
Sections 5.4 and 5.5). Theoretically, this configuration choice Section 7). Theoretically, this configuration choice could be
could be negotiated for each pair of PCN-boundary-nodes, but we negotiated for each pair of PCN-boundary-nodes, but we cannot
cannot imagine why such complexity would be required, except imagine why such complexity would be required, except perhaps in
perhaps in future inter-domain scenarios. future inter-domain scenarios.
PCN-egress-nodes will have further system options: PCN-egress-nodes will have further system options:
o How the mapping should be established between each packet and its o How the mapping should be established between each packet and its
aggregate, eg by MPLS label, by IP packet filterspec; and how to aggregate, eg by MPLS label, by IP packet filterspec; and how to
take account of ECMP. take account of ECMP.
o If an equipment vendor provides a choice, there may be options to o If an equipment vendor provides a choice, there may be options to
select which smoothing algorithm to use for measurements. select which smoothing algorithm to use for measurements.
8.1.2. Parameters 9.1.2. Parameters
Like any DiffServ domain, every node within a PCN-domain will need to 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 be configured with the DSCP(s) used to identify PCN-packets. On each
interior link the main configuration parameters are the PCN-lower- interior link the main configuration parameters are the PCN-
rate and PCN-upper-rate. A larger PCN-lower-rate enables more PCN- threshold-rate and PCN-excess-rate. A larger PCN-threshold-rate
traffic to be admitted on a link, hence improving capacity enables more PCN-traffic to be admitted on a link, hence improving
utilisation. A PCN-upper-rate set further above the PCN-lower-rate capacity utilisation. A PCN-excess-rate set further above the PCN-
allows greater increases in traffic (whether due to natural threshold-rate allows greater increases in traffic (whether due to
fluctuations or some unexpected event) before any flows are natural fluctuations or some unexpected event) before any flows are
terminated, ie minimises the chances of unnecessarily triggering the terminated, ie minimises the chances of unnecessarily triggering the
termination mechanism. For instance an operator may want to design termination mechanism. For instance an operator may want to design
their network so that it can cope with a failure of any single PCN- their network so that it can cope with a failure of any single PCN-
node without terminating any flows. node without terminating any flows.
Setting these rates on first deployment of PCN will be very similar Setting these rates on first deployment of PCN will be very similar
to the traditional process for sizing an admission controlled to the traditional process for sizing an admission controlled
network, depending on: the operator's requirements for minimising network, depending on: the operator's requirements for minimising
flow blocking (grade of service), the expected PCN traffic load on flow blocking (grade of service), the expected PCN traffic load on
each link and its statistical characteristics (the traffic matrix), each link and its statistical characteristics (the traffic matrix),
contingency for re-routing the PCN traffic matrix in the event of contingency for re-routing the PCN traffic matrix in the event of
single or multiple failures and the expected load from other classes single or multiple failures and the expected load from other classes
relative to link capacities [Menth]. But once a domain is up and relative to link capacities [Menth]. But once a domain is up and
running, a PCN design goal is to be able to determine growth in these running, a PCN design goal is to be able to determine growth in these
configured rates much more simply, by monitoring PCN-marking rates configured rates much more simply, by monitoring PCN-marking rates
from actual rather than expected traffic (see Section 8.2 on from actual rather than expected traffic (see Section 9.2 on
Performance & Provisioning). Performance & Provisioning).
Operators may also wish to configure a rate greater than the PCN- Operators may also wish to configure a rate greater than the PCN-
upper-rate that is the absolute maximum rate that a link allows for 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 PCN-traffic. This may simply be the physical link rate, but some
operators may wish to configure a logical limit to prevent starvation operators may wish to configure a logical limit to prevent starvation
of other traffic classes during any brief period after PCN-traffic of other traffic classes during any brief period after PCN-traffic
exceeds the PCN-upper-rate but before flow termination brings it back exceeds the PCN-excess-rate but before flow termination brings it
below this rate. back below this rate.
Specific marking algorithms will also depend on further configuration Specific marking algorithms will also depend on further configuration
parameters. For instance, threshold-marking will require a threshold parameters. For instance, threshold-marking will require a threshold
queue depth and excess-rate-marking may require a scaling parameter. queue depth and excess-traffic-marking may require a scaling
It will be preferable for each marking algorithm to have rules to set parameter. It will be preferable for each marking algorithm to have
defaults for these parameters relative to the reference marking rate, rules to set defaults for these parameters relative to the reference
but then allow operators to change them, for instance if average marking rate, but then allow operators to change them, for instance
traffic characteristics change over time. The PCN-egress-node may if average traffic characteristics change over time. The PCN-egress-
allow configuration of the following: node may allow configuration of the following:
o how it smoothes metering of PCN-markings (eg EWMA parameters) o how it smooths metering of PCN-markings (eg EWMA parameters)
Whichever node makes admission and flow termination decisions will Whichever node makes admission and flow termination decisions will
contain algorithms for converting PCN-marking levels into admission contain algorithms for converting PCN-marking levels into admission
or flow termination decisions. These will also require configurable or flow termination decisions. These will also require configurable
parameters, for instance: parameters, for instance:
o Any admission control algorithm will at least require a marking o any admission control algorithm will at least require a marking
threshold setting above which it denies admission to new flows; threshold setting above which it denies admission to new flows;
o flow termination algorithms will probably require a parameter to o flow termination algorithms will probably require a parameter to
delay termination of any flows until it is more certain that an delay termination of any flows until it is more certain that an
anomalous event is not transient; anomalous event is not transient;
o a parameter to control the trade-off between how quickly excess o a parameter to control the trade-off between how quickly excess
flows are terminated and over-termination. flows are terminated and over-termination.
One particular proposal, [I-D.charny-pcn-single-marking] would One particular proposal, [I-D.charny-pcn-single-marking] would
require a global parameter to be defined on all PCN-nodes, but only require a global parameter to be defined on all PCN-nodes, but only
needs the PCN-lower-rate to be configured on each link. The global needs one PCN marking rate to be configured on each link. The global
parameter is a scaling factor between admission and termination, for parameter is a scaling factor between admission and termination, for
example the amount by which the PCN-upper-rate is implicitly assumed example the amount by which the PCN-excess-rate is implicitly assumed
to be above the PCN-lower-rate. [I-D.charny-pcn-single-marking] to be above the PCN-threshold-rate. [I-D.charny-pcn-single-marking]
discusses in full the impact of this particular proposal on the discusses in full the impact of this particular proposal on the
operation of PCN. operation of PCN.
8.2. Performance & Provisioning OAM 9.2. Performance & Provisioning OAM
Monitoring of performance factors measurable from *outside* the PCN Monitoring of performance factors measurable from *outside* the PCN
domain will be no different with PCN than with any other packet-based domain will be no different with PCN than with any other packet-based
flow admission control system, both at the flow level (blocking flow admission control system, both at the flow level (blocking
probability etc) and the packet level (jitter [RFC3393], [Y.1541], probability etc) and the packet level (jitter [RFC3393], [Y.1541],
loss rate [RFC4656], mean opinion score [P.800], etc). The loss rate [RFC4656], mean opinion score [P.800], etc). The
difference is that PCN is intentionally designed to indicate difference is that PCN is intentionally designed to indicate
*internally* which exact resource(s) are the cause of performance *internally* which exact resource(s) are the cause of performance
problems and by how much. problems and by how much.
skipping to change at page 34, line 9 skipping to change at page 31, line 40
Alternatively, before triggering an upgrade, the long term pre- Alternatively, before triggering an upgrade, the long term pre-
congestion volume on each link can be used to balance traffic load congestion volume on each link can be used to balance traffic load
across the PCN-domain by adjusting the link weights of the routing across the PCN-domain by adjusting the link weights of the routing
system. When an upgrade to a link's configured PCN-rates is system. When an upgrade to a link's configured PCN-rates is
required, it may also be necessary to upgrade the physical capacity required, it may also be necessary to upgrade the physical capacity
available to other classes. But usually there will be sufficient available to other classes. But usually there will be sufficient
physical capacity for the upgrade to go ahead as a simple physical capacity for the upgrade to go ahead as a simple
configuration change. Alternatively, [Songhurst] has proposed an configuration change. Alternatively, [Songhurst] has proposed an
adaptive rather than preconfigured system, where the configured PCN- adaptive rather than preconfigured system, where the configured PCN-
lower-rate is replaced with a high and low water mark and the marking threshold-rate is replaced with a high and low water mark and the
algorithm automatically optimises how physical capacity is shared marking algorithm automatically optimises how physical capacity is
using the relative loads from PCN and other traffic classes. shared using the relative loads from PCN and other traffic classes.
All the above processes require just three extra counters associated All the above processes require just three extra counters associated
with each PCN queue: PCN-markings associated with the PCN-lower-rate with each PCN queue: threshold-markings, excess-traffic-markings and
and PCN-upper-rate, and drop. Every time a PCN packet is marked or drop. Every time a PCN packet is marked or dropped its size in bytes
dropped its size in bytes should be added to the appropriate counter. should be added to the appropriate counter. Then the management
Then the management system can read the counters at any time and system can read the counters at any time and subtract a previous
subtract a previous reading to establish the incremental volume of reading to establish the incremental volume of each type of
each type of (pre-)congestion. Readings should be taken frequently, (pre-)congestion. Readings should be taken frequently, so that
so that anomalous events (eg re-routes) can be separated from regular anomalous events (eg re-routes) can be separated from regular
fluctuating demand if required. fluctuating demand if required.
8.3. Accounting OAM 9.3. Accounting OAM
Accounting is only done at trust boundaries so it is out of scope of Accounting is only done at trust boundaries so it is out of scope of
the initial Charter of the PCN WG which is confined to intra-domain the initial Charter of the PCN WG which is confined to intra-domain
issues. Use of PCN internal to a domain makes no difference to the issues. Use of PCN internal to a domain makes no difference to the
flow signalling events crossing trust boundaries outside the PCN- flow signalling events crossing trust boundaries outside the PCN-
domain, which are typically used for accounting. domain, which are typically used for accounting.
8.4. Fault OAM 9.4. Fault OAM
Fault OAM is about preventing faults, telling the management system Fault OAM is about preventing faults, telling the management system
(or manual operator) that the system has recovered (or not) from a (or manual operator) that the system has recovered (or not) from a
failure, and about maintaining information to aid fault diagnosis. failure, and about maintaining information to aid fault diagnosis.
Admission blocking and particularly flow termination mechanisms Admission blocking and particularly flow termination mechanisms
should rarely be needed in practice. It would be unfortunate if they should rarely be needed in practice. It would be unfortunate if they
didn't work after an option had been accidentally disabled. didn't work after an option had been accidentally disabled.
Therefore it will be necessary to regularly test that the live system Therefore it will be necessary to regularly test that the live system
works as intended (devising a meaningful test is left as an exercise works as intended (devising a meaningful test is left as an exercise
for the operator). for the operator).
Section 5.9 describes how the PCN architecture has been designed to Section 7 describes how the PCN architecture has been designed to
ensure admitted flows continue gracefully after recovering ensure admitted flows continue gracefully after recovering
automatically from link or node failures. The need to record and automatically from link or node failures. The need to record and
monitor re-routing events affecting signalling is unchanged by the monitor re-routing events affecting signalling is unchanged by the
addition of PCN to a DiffServ domain. Similarly, re-routing events addition of PCN to a DiffServ domain. Similarly, re-routing events
within the PCN-domain will be recorded and monitored just as they within the PCN-domain will be recorded and monitored just as they
would be without PCN. would be without PCN.
PCN-marking does make it possible to record 'near-misses'. For PCN-marking does make it possible to record 'near-misses'. For
instance, at the PCN-egress-node a 'reporting threshold' could be set 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 to monitor how often - and for how long - the system comes close to
triggering flow blocking without actually doing so. Similarly, triggering flow blocking without actually doing so. Similarly,
bursts of flow termination marking could be recorded even if they are bursts of flow termination marking could be recorded even if they are
not sufficiently sustained to trigger flow termination. Such not sufficiently sustained to trigger flow termination. Such
statistics could be correlated with per-queue counts of marking statistics could be correlated with per-queue counts of marking
volume (Section 8.2) to upgrade resources in danger of causing volume (Section 9.2) to upgrade resources in danger of causing
service degradation, or to trigger manual tracing of intermittent service degradation, or to trigger manual tracing of intermittent
incipient errors that would otherwise have gone unnoticed. incipient errors that would otherwise have gone unnoticed.
Finally, of course, many faults are caused by failings in the Finally, of course, many faults are caused by failings in the
management process ('human error'): a wrongly configured address in a management process ('human error'): a wrongly configured address in a
node, a wrong address given in a signalling protocol, a wrongly node, a wrong address given in a signalling protocol, a wrongly
configured parameter in a queueing algorithm, a node set into a configured parameter in a queueing algorithm, a node set into a
different mode from other nodes, and so on. Generally, a clean different mode from other nodes, and so on. Generally, a clean
design with few configurable options ensures this class of faults can design with few configurable options ensures this class of faults can
be traced more easily and prevented more often. Sound management be traced more easily and prevented more often. Sound management
practice at run-time also helps. For instance: a management system practice at run-time also helps. For instance: a management system
should be used that constrains configuration changes within system should be used that constrains configuration changes within system
rules (eg preventing an option setting inconsistent with other rules (eg preventing an option setting inconsistent with other
nodes); configuration options should also be recorded in an offline nodes); configuration options should also be recorded in an offline
database; and regular automatic consistency checks between live database; and regular automatic consistency checks between live
systems and the database. PCN adds nothing specific to this class of systems and the database. PCN adds nothing specific to this class of
problems. By the time standards are in place, we expect that the PCN problems. By the time standards are in place, we expect that the PCN
WG will have ruthlessly removed gratuitous configuration choices. WG will have ruthlessly removed gratuitous configuration choices.
However, at the time of writing, the WG is yet to choose between However, at the time of writing, the WG is yet to choose between
multiple competing proposals, so the range of possible options in multiple competing proposals, so the range of possible options in
Section 8.1 does seem rather wide compared to the original near-zero Section 9.1 does seem rather wide compared to the original near-zero
configuration intent of the architecture. configuration intent of the architecture.
8.5. Security OAM 9.5. Security OAM
Security OAM is about using secure operational practices as well as Security OAM is about using secure operational practices as well as
being able to track security breaches or near-misses at run-time. being able to track security breaches or near-misses at run-time.
PCN adds few specifics to the general good practice required in this PCN adds few specifics to the general good practice required in this
field [RFC4778], other than those below. The correct functions of field [RFC4778], other than those below. The correct functions of
the system should be monitored (Section 8.2) in multiple independent the system should be monitored (Section 9.2) in multiple independent
ways and correlated to detect possible security breaches. Persistent ways and correlated to detect possible security breaches. Persistent
(pre-)congestion marking should raise an alarm (both on the node (pre-)congestion marking should raise an alarm (both on the node
doing the marking and on the PCN-egress-node metering it). doing the marking and on the PCN-egress-node metering it).
Similarly, persistently poor external QoS metrics such as jitter or Similarly, persistently poor external QoS metrics such as jitter or
MOS should raise an alarm. The following are examples of symptoms MOS should raise an alarm. The following are examples of symptoms
that may be the result of innocent faults, rather than attacks, but that may be the result of innocent faults, rather than attacks, but
until diagnosed they should be logged and trigger a security alarm: until diagnosed they should be logged and trigger a security alarm:
o Anomalous patterns of non-conforming incoming signals and packets o Anomalous patterns of non-conforming incoming signals and packets
rejected at the PCN-ingress-nodes (eg packets already marked PCN- rejected at the PCN-ingress-nodes (eg packets already marked PCN-
skipping to change at page 36, line 23 skipping to change at page 34, line 5
o A PCN-ingress-node receiving feedback signals about the pre- o A PCN-ingress-node receiving feedback signals about the pre-
congestion level on a non-existent aggregate, or that are congestion level on a non-existent aggregate, or that are
inconsistent with other signals (eg unexpected sequence numbers, inconsistent with other signals (eg unexpected sequence numbers,
inconsistent addressing, conflicting reports of the pre-congestion inconsistent addressing, conflicting reports of the pre-congestion
level, etc). level, etc).
o Pre-congestion marking arriving at an PCN-egress-node with o Pre-congestion marking arriving at an PCN-egress-node with
(pre-)congestion markings focused on particular flows, rather than (pre-)congestion markings focused on particular flows, rather than
randomly distributed throughout the aggregate. randomly distributed throughout the aggregate.
9. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security considerations 11. Security considerations
Security considerations essentially come from the Trust Assumption Security considerations essentially come from the Trust Assumption
(Section 3.1), ie that all PCN-nodes are PCN-enabled and trust each (Section 5.1), ie that all PCN-nodes are PCN-enabled and trust each
other for truthful PCN-marking and transport. PCN splits other for truthful PCN-marking and transport. PCN splits
functionality between PCN-interior-nodes and PCN-boundary-nodes, and functionality between PCN-interior-nodes and PCN-boundary-nodes, and
the security considerations are somewhat different for each, mainly the security considerations are somewhat different for each, mainly
because PCN-boundary-nodes are flow-aware and PCN-interior-nodes are because PCN-boundary-nodes are flow-aware and PCN-interior-nodes are
not. not.
o because the PCN-boundary-nodes are flow-aware, they are trusted to o Because the PCN-boundary-nodes are flow-aware, they are trusted to
use that awareness correctly. The degree of trust required use that awareness correctly. The degree of trust required
depends on the kinds of decisions they have to make and the kinds depends on the kinds of decisions they have to make and the kinds
of information they need to make them. For example when the PCN- of information they need to make them. For example when the PCN-
boundary-node needs to know the contents of the sessions for boundary-node needs to know the contents of the sessions for
making the admission and termination decisions, or when the making the admission and termination decisions, or when the
contents are highly classified, then the security requirements for contents are highly classified, then the security requirements for
the PCN-boundary-nodes involved will also need to be high. the PCN-boundary-nodes involved will also need to be high.
o the PCN-ingress-nodes police packets to ensure a PCN-flow sticks o the PCN-ingress-nodes police packets to ensure a PCN-flow sticks
within its agreed limit, and to ensure that only PCN-flows which within its agreed limit, and to ensure that only PCN-flows which
have been admitted contribute PCN-traffic into the PCN-domain. have been admitted contribute PCN-traffic into the PCN-domain.
The policer must drop (or perhaps re-mark to a different DSCP) any The policer must drop (or perhaps downgrade to a different DSCP)
PCN-packets received that are outside this remit. This is similar any PCN-packets received that are outside this remit. This is
to the existing IntServ behaviour. Between them the PCN-boundary- similar to the existing IntServ behaviour. Between them the PCN-
nodes must encircle the PCN-domain, otherwise PCN-packets could boundary-nodes must encircle the PCN-domain, otherwise PCN-packets
enter the PCN-domain without being subject to admission control, could enter the PCN-domain without being subject to admission
which would potentially destroy the QoS of existing flows. control, which would potentially destroy the QoS of existing
flows.
o PCN-interior-nodes aren't flow-aware. This prevents some security o PCN-interior-nodes aren't flow-aware. This prevents some security
attacks where an attacker targets specific flows in the data plane attacks where an attacker targets specific flows in the data plane
- for instance for DoS or eavesdropping. - for instance for DoS or eavesdropping.
o PCN-marking by the PCN-interior-nodes along the packet forwarding o PCN-marking by the PCN-interior-nodes along the packet forwarding
path needs to be trusted, because the PCN-boundary-nodes rely on path needs to be trusted, because the PCN-boundary-nodes rely on
this information. For instance a rogue PCN-interior-node could this information. For instance a rogue PCN-interior-node could
PCN-mark all packets so that no flows were admitted. Another PCN-mark all packets so that no flows were admitted. Another
possibility is that it doesn't PCN-mark any packets, even when possibility is that it doesn't PCN-mark any packets, even when
skipping to change at page 37, line 39 skipping to change at page 35, line 21
the recipient needs to validate that the message is indeed from the recipient needs to validate that the message is indeed from
the node that claims to have sent it. Possible measures include the node that claims to have sent it. Possible measures include
digest authentication and protection against replay and man-in- digest authentication and protection against replay and man-in-
the-middle attacks. For the specific protocol RSVP, hop-by-hop the-middle attacks. For the specific protocol RSVP, hop-by-hop
authentication is in [RFC2747], and authentication is in [RFC2747], and
[I-D.behringer-tsvwg-rsvp-security-groupkeying] may also be [I-D.behringer-tsvwg-rsvp-security-groupkeying] may also be
useful; for a generic signalling protocol the PCN WG document on useful; for a generic signalling protocol the PCN WG document on
"Requirements for signalling" will describe the requirements in "Requirements for signalling" will describe the requirements in
more detail. more detail.
Operational security advice is given in Section 8.5. Operational security advice is given in Section 9.5.
11. Conclusions 12. Conclusions
The document describes a general architecture for flow admission and The document describes a general architecture for flow admission and
termination based on pre-congestion information in order to protect termination based on pre-congestion information in order to protect
the quality of service of established inelastic flows within a single the quality of service of established inelastic flows within a single
DiffServ domain. The main topic is the functional architecture DiffServ domain. The main topic is the functional architecture. It
(first covered at a high level and then at a greater level of also mentions other topics like the assumptions and open issues.
detail). It also mentions other topics like the assumptions and open
issues.
12. Acknowledgements 13. Acknowledgements
This document is a revised version of [I-D.eardley-pcn-architecture]. This document is a revised version of [I-D.eardley-pcn-architecture].
Its authors were: P. Eardley, J. Babiarz, K. Chan, A. Charny, R. Its authors were: P. Eardley, J. Babiarz, K. Chan, A. Charny, R.
Geib, G. Karagiannis, M. Menth, T. Tsou. They are therefore Geib, G. Karagiannis, M. Menth, T. Tsou. They are therefore
contributors to this document. contributors to this document.
Thanks to those who've made comments on Thanks to those who've made comments on
[I-D.eardley-pcn-architecture] and on earlier versions of this draft: [I-D.eardley-pcn-architecture] and on earlier versions of this draft:
Lachlan Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake, Lachlan Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake,
Bob Briscoe, Ken Carlberg, Anna Charny, Joachim Charzinski, Andras Bob Briscoe, Jason Canon, Ken Carlberg, Anna Charny, Joachim
Csaszar, Lars Eggert, Ruediger Geib, Robert Hancock, Ingemar Charzinski, Andras Csaszar, Lars Eggert, Ruediger Geib, Wei Gengyu,
Johansson, Georgios Karagiannis, Michael Menth, Tom Taylor, Hannes Robert Hancock, Ingemar Johansson, Georgios Karagiannis, Michael
Tschofenig, Tina Tsou, Magnus Westerlund, Delei Yu. Thanks to Bob Menth, Toby Moncaster, 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 Briscoe who extensively revised the Operations and Management
section. section.
This document is the result of discussions in the PCN WG and This document is the result of discussions in the PCN WG and
forerunner activity in the TSVWG. A number of previous drafts were forerunner activity in the TSVWG. A number of previous drafts were
presented to TSVWG: [I-D.chan-pcn-problem-statement], presented to TSVWG: [I-D.chan-pcn-problem-statement],
[I-D.briscoe-tsvwg-cl-architecture], [I-D.briscoe-tsvwg-cl-phb], [I-D.briscoe-tsvwg-cl-architecture], [I-D.briscoe-tsvwg-cl-phb],
[I-D.charny-pcn-single-marking], [I-D.babiarz-pcn-sip-cap], [I-D.charny-pcn-single-marking], [I-D.babiarz-pcn-sip-cap],
[I-D.lefaucheur-rsvp-ecn], [I-D.westberg-pcn-load-control]. The [I-D.lefaucheur-rsvp-ecn], [I-D.westberg-pcn-load-control]. The
authors of them were: B, Briscoe, P. Eardley, D. Songhurst, F. Le authors of them were: B, Briscoe, P. Eardley, D. Songhurst, F. Le
Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley, G. Karagiannis, Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley, G. Karagiannis,
A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G. Liu, A. Bhargava. A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G. Liu, A. Bhargava.
13. Comments Solicited 14. Comments Solicited
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF PCN working group mailing list <pcn@ietf.org>. addressed to the IETF PCN working group mailing list <pcn@ietf.org>.
14. Changes 15. Changes
14.1. Changes from -02 to -03 15.1. Changes from -03 to -04
o Minor changes throughout to reflect the consenus call about PCN-
marking (as reflected in [I-D.eardley-pcn-marking-behaviour]).
o Minor changes throughout to reflect the current decisions about
encoding (as reflected in [I-D.moncaster-pcn-baseline-encoding]and
[I-D.moncaster-pcn-3-state-encoding]).
o Introduction: re-structured to create new sections on Benefits,
Deployment scenarios and Assumptions.
o Introduction: Added pointers to other PCN documents.
o Terminology: changed PCN-lower-rate to PCN-threshold-rate and PCN-
upper-rate to PCN-excess-rate; excess-rate-marking to excess-
traffic-marking.
o Benefits: added bullet about SRLGs.
o Deployment scenarios: new section combining material from various
places within the document.
o S6 (high level functional architecture): re-structured and edited
to improve clarity, and reflect the latest PCN-marking and
encoding drafts.
o S6.4: added claim that the most natural place to make an admission
decision is a PCN-egress-node.
o S6.5: updated the bullet about non-PCN-traffic that uses the same
DSCP as PCN-traffic.
o S6.6: added a section about backwards compatibility with respect
to [RFC4774].
o Appendix A: added bullet about end-to-end PCN.
o Probing: moved to Appendix B.
o Other minor clarifications, typos etc.
15.2. Changes from -02 to -03
o Abstract: Clarified by removing the term 'aggregated'. Follow-up o Abstract: Clarified by removing the term 'aggregated'. Follow-up
clarifications later in draft: S1: expanded PCN-egress-nodes clarifications later in draft: S1: expanded PCN-egress-nodes
bullet to mention case where the PCN-feedback-information is about bullet to mention case where the PCN-feedback-information is about
one (or a few) PCN-marks, rather than aggregated information; S3 one (or a few) PCN-marks, rather than aggregated information; S3
clarified PCN-meter; S5 minor changes; conclusion. clarified PCN-meter; S5 minor changes; conclusion.
o S1: added a paragraph about how the PCN-domain looks to the o S1: added a paragraph about how the PCN-domain looks to the
outside world (essentially it looks like a DiffServ domain). outside world (essentially it looks like a DiffServ domain).
skipping to change at page 39, line 44 skipping to change at page 38, line 19
behaviours for different ingress-egress-aggregates within the same behaviours for different ingress-egress-aggregates within the same
PCN-domain. PCN-domain.
o Appendix: Created an Appendix about "Possible work items beyond o Appendix: Created an Appendix about "Possible work items beyond
the scope of the current PCN WG Charter". Material moved from the scope of the current PCN WG Charter". Material moved from
near start of S3 and elsewhere throughout draft. Moved text about near start of S3 and elsewhere throughout draft. Moved text about
centralised decision node to Appendix. centralised decision node to Appendix.
o Other minor clarifications. o Other minor clarifications.
14.2. Changes from -01 to -02 15.3. Changes from -01 to -02
o S1: Benefits: provisioning bullet extended to stress that PCN does o S1: Benefits: provisioning bullet extended to stress that PCN does
not use RFC2475-style traffic conditioning. not use RFC2475-style traffic conditioning.
o S1: Deployment models: mentioned, as variant of PCN-domain o S1: Deployment models: mentioned, as variant of PCN-domain
extending to end nodes, that may extend to LAN edge switch. extending to end nodes, that may extend to LAN edge switch.
o S3.1: Trust Assumption: added note about not needing PCN-marking o S3.1: Trust Assumption: added note about not needing PCN-marking
capability if known that an interface cannot become pre-congested. capability if known that an interface cannot become pre-congested.
skipping to change at page 40, line 31 skipping to change at page 39, line 5
o S5.8: Tunnelling: added case of "partially PCN-capable tunnel" and o S5.8: Tunnelling: added case of "partially PCN-capable tunnel" and
degraded bullet on this in S6 (Open Issues) degraded bullet on this in S6 (Open Issues)
o S7: Probing: new section. Much more comprehensive than old S5.5. o S7: Probing: new section. Much more comprehensive than old S5.5.
o S8: Operations and Management: substantially revised. o S8: Operations and Management: substantially revised.
o other minor changes not affecting semantics o other minor changes not affecting semantics
14.3. Changes from -00 to -01 15.4. Changes from -00 to -01
In addition to clarifications and nit squashing, the main changes In addition to clarifications and nit squashing, the main changes
are: are:
o S1: Benefits: added one about provisioning (and contrast with o S1: Benefits: added one about provisioning (and contrast with
DiffServ SLAs) DiffServ SLAs)
o S1: Benefits: clarified that the objective is also to stop PCN- o S1: Benefits: clarified that the objective is also to stop PCN-
packets being significantly delayed (previously only mentioned not packets being significantly delayed (previously only mentioned not
dropping packets) dropping packets)
skipping to change at page 42, line 4 skipping to change at page 40, line 24
of scope for this document" and edited a couple of sentences that of scope for this document" and edited a couple of sentences that
were close to solution space. were close to solution space.
o S6: Open issues: added one about scenarios with only one tunnel o S6: Open issues: added one about scenarios with only one tunnel
endpoint in the PCN domain . endpoint in the PCN domain .
o S6: Open issues: ECMP: added under-admission as another potential o S6: Open issues: ECMP: added under-admission as another potential
risk risk
o S6: Open issues: added one about "Silent at start" o S6: Open issues: added one about "Silent at start"
o S10: Conclusions: a small conclusions section added o S10: Conclusions: a small conclusions section added
15. Appendix A: Possible work items beyond the scope of the current PCN 16. Appendix A: Possible work items beyond the scope of the current PCN
WG Charter WG Charter
This section mentions some topics that are outside the PCN WG's This section mentions some topics that are outside the PCN WG's
current Charter, but which have been mentioned as areas of interest. current Charter, but which have been mentioned as areas of interest.
They might be work items for: the PCN WG after a future re- They might be work items for: the PCN WG after a future re-
chartering; some other IETF WG; another standards body; an operator- chartering; some other IETF WG; another standards body; an operator-
specific usage that's not standardised. specific usage that's not standardised.
NOTE: it should be crystal clear that this section discusses NOTE: it should be crystal clear that this section discusses
possibilities only. possibilities only.
skipping to change at page 42, line 47 skipping to change at page 41, line 21
that adapts according to the pre-congestion information. that adapts according to the pre-congestion information.
o the aggregation assumption doesn't hold, because the link capacity o the aggregation assumption doesn't hold, because the link capacity
is too low. Measurement-based admission control is then risky. is too low. Measurement-based admission control is then risky.
o the applicability of PCN mechanisms for emergency use (911, GETS, o the applicability of PCN mechanisms for emergency use (911, GETS,
WPS, MLPP, etc.) WPS, MLPP, etc.)
Other possibilities include: Other possibilities include:
o The PCN-domain extends to the end users. The scenario is
described in [I-D.babiarz-pcn-sip-cap]. The end users need to be
trusted to do their own policing. This scenario is in the scope
of the PCN WG charter if there is sufficient traffic for the
aggregation assumption to hold. A variant is that the PCN-domain
extends out as far as the LAN edge switch.
o indicating pre-congestion through signalling messages rather than o indicating pre-congestion through signalling messages rather than
in-band (in the form of PCN-marked packets) in-band (in the form of PCN-marked packets)
o the decision-making functionality is at a centralised node rather o the decision-making functionality is at a centralised node rather
than at the PCN-boundary-nodes. This requires that the PCN- than at the PCN-boundary-nodes. This requires that the PCN-
egress-node signals PCN-feedback-information to the centralised egress-node signals PCN-feedback-information to the centralised
node, and that the centralised node signals to the PCN-ingress- node, and that the centralised node signals to the PCN-ingress-
node about the decision about admission (or termination). It may node about the decision about admission (or termination). It may
also need the centralised node and the PCN-boundary-nodes to know also need the centralised node and the PCN-boundary-nodes to know
each others addresses. It would be possible for the centralised each other's addresses. It would be possible for the centralised
node to be one of the PCN-boundary-nodes, when clearly the node to be one of the PCN-boundary-nodes, when clearly the
signalling would sometimes be replaced by a message internal to signalling would sometimes be replaced by a message internal to
the node. the node.
o It would be possible for the centralised node to be one of the o Signalling extensions for specific protocols (eg RSVP, NSIS). For
PCN-boundary-nodes, when clearly the signalling would sometimes be
replaced by a message internal to the node.
o signalling extensions for specific protocols (eg RSVP, NSIS). For
example: the details of how the signalling protocol installs the example: the details of how the signalling protocol installs the
flowspec at the PCN-ingress-node for an admitted PCN-flow; and how flowspec at the PCN-ingress-node for an admitted PCN-flow; and how
the signalling protocol carries the PCN-feedback-information. the signalling protocol carries the PCN-feedback-information.
Perhaps also for other functions such as: coping with failure of a Perhaps also for other functions such as: coping with failure of a
PCN-boundary-node ([I-D.briscoe-tsvwg-cl-architecture] considers PCN-boundary-node ([I-D.briscoe-tsvwg-cl-architecture] considers
what happens if RSVP is the QoS signalling protocol); establishing what happens if RSVP is the QoS signalling protocol); establishing
a tunnel across the PCN-domain if it is necessary to carry ECN a tunnel across the PCN-domain if it is necessary to carry ECN
marks transparently. Note: There is a PCN WG Milestone on marks transparently. Note: There is a PCN WG Milestone on
"Requirements for signalling", which is potential input for the "Requirements for signalling", which is potential input for the
appropriate WGs. appropriate WGs.
o policing by the PCN-ingress-node may not be needed if the PCN- o Policing by the PCN-ingress-node may not be needed if the PCN-
domain can trust that the upstream network has already policed the domain can trust that the upstream network has already policed the
traffic on its behalf. traffic on its behalf.
o PCN for Pseudowire: PCN may be used as a congestion avoidance o PCN for Pseudowire: PCN may be used as a congestion avoidance
mechanism for edge to edge pseudowire emulations mechanism for edge to edge pseudowire emulations
[I-D.ietf-pwe3-congestion-frmwk]. [I-D.ietf-pwe3-congestion-frmwk].
o PCN for MPLS: [RFC3270] defines how to support the DiffServ o PCN for MPLS: [RFC3270] defines how to support the DiffServ
architecture in MPLS networks. [RFC5129] describes how to add PCN architecture in MPLS networks. [RFC5129] describes how to add PCN
for admission control of microflows into a set of MPLS aggregates for admission control of microflows into a set of MPLS aggregates
(Multi-protocol label switching). PCN-marking is done in MPLS's (Multi-protocol label switching). PCN-marking is done in MPLS's
EXP field. EXP field (which [I-D.andersson-mpls-expbits-def] proposes to re-
name to the Class of Service (CoS) bits).
o PCN for Ethernet: Similarly, it may be possible to extend PCN into o PCN for Ethernet: Similarly, it may be possible to extend PCN into
Ethernet networks, where PCN-marking is done in the Ethernet Ethernet networks, where PCN-marking is done in the Ethernet
header. header. NOTE: Specific consideration of this extension is outside
the IETF's remit.
. .
16. Informative References 17. Appendix B: Probing
17.1. Introduction
Probing is an optional 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 the link that's
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. Another possibility is that a probe packet is a signalling
packet that is anyway travelling from the PCN-ingress-node to the
PCN-egress-node (eg an RSVP PATH message travelling from source to
destination).
17.2. Probing functions
The probing functions are:
o Make decision that probing is needed. As described above, this is
when the ingress-egress-aggregate (or the ECMP path - Section 8)
carries no PCN-traffic. An alternative is always to probe, ie
probe before admitting every PCN-flow.
o (if required) Communicate the request that probing is needed - the
PCN-egress-node signals to the PCN-ingress-node that probing is
needed
o (if required) Generate probe traffic - the PCN-ingress-node
generates the probe traffic. The appropriate number (or rate) of
probe packets will depend on the PCN-marking algorithm; for
example an excess-traffic-marking algorithm generates fewer PCN-
marks than a threshold-marking algorithm, and so will need more
probe packets.
o Forward probe packets - as far as PCN-interior-nodes are
concerned, probe packets are handled the same as (ordinary data)
PCN-packets, in terms of routing, scheduling and PCN-marking.
o Consume probe packets - the PCN-egress-node consumes probe packets
to ensure that they don't travel beyond the PCN-domain.
17.3. Discussion of rationale for probing, its downsides and open
issues
It is an unresolved question whether probing is really needed, but
three 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. The third viewpoint is that
admission control is always done by probing. We now consider each in
turn.
The first viewpoint assumes the following:
o There is no PCN-traffic on the ingress-egress-aggregate (so a
normal admission decision cannot be made).
o Simply admitting the new flow has a significant risk of leading to
overload: packets dropped or flows terminated.
On the former bullet, [PCN-email-traffic-empty-aggregates] 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 a new flow starts on many of the
empty ingress-egress-aggregates and causes overload on 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,
and also flows naturally end anyway.
The downsides of probing for this viewpoint are:
o Probing adds delay to the admission control process.
o Sufficient probing traffic has to be generated to test the pre-
congestion level of the ingress-egress-aggregate. But the probing
traffic itself may cause pre-congestion, causing other PCN-flows
to be blocked or even terminated - and in the flash crowd scenario
there will be probing on many ingress-egress-aggregates.
The open issues associated with this viewpoint include:
o What rate and pattern of probe packets does the PCN-ingress-node
need to generate, so that there's enough traffic to make the
admission decision?
o What difficulty does the delay (whilst probing is done) cause
applications, eg packets might be dropped?
o Are there other ways of dealing with the flash crowd scenario?
For instance limit the rate at which new flows are admitted; or
perhaps for a PCN-egress-node to block new flows on its empty
ingress-egress-aggregates when its non-empty ones are pre-
congested.
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:
o there's a significant chance that the traffic is unevenly balanced
across the ECMP paths, and hence there's a significant risk of
admitting a flow that should be blocked (because it follows an
ECMP path that is pre-congested) or blocking a flow that should be
admitted.
o Note: [PCN-email-ECMP] suggests unbalanced traffic is quite
possible, even with quite a large number of flows on a PCN-link
(eg 1000) when Assumption 3 (aggregation) is likely to be
satisfied.
(2) If admission control is based on measurements of pre-congestion
on specific ECMP paths, then the viewpoint that probing is useful
assumes:
o There is no PCN-traffic on the ECMP path on which to base an
admission decision.
o Simply admitting the new flow has a significant risk of leading to
overload.
o The PCN-egress-node can match a packet to an ECMP path.
o Note: This is similar to the first viewpoint and so similarly
could occur in a flash crowd if a new flow starts more-or-less
simultaneously on many of the empty ECMP paths. Because there are
several (sometimes many) ECMP paths between each pair of PCN-
boundary-nodes, it's presumably more likely that an ECMP path is
'empty' than an ingress-egress-aggregate. To constrain the number
of ECMP paths, a few tunnels could be set-up between each pair of
PCN-boundary-nodes. Tunnelling also solves the third bullet
(which is otherwise hard because an ECMP routing decision is made
independently on each node).
The downsides of probing for this viewpoint are:
o Probing adds delay to the admission control process.
o Sufficient probing traffic has to be generated to test the pre-
congestion level of the ECMP path. But there's the risk that the
probing traffic itself may cause pre-congestion, causing other
PCN-flows to be blocked or even terminated.
o The PCN-egress-node needs to consume the probe packets to ensure
they don't travel beyond the PCN-domain (eg they might confuse the
destination end node). Hence somehow the PCN-egress-node has to
be able to disambiguate a probe packet from a data packet, via the
characteristic setting of particular bit(s) in the packet's header
or body - but these bit(s) mustn't be used by any PCN-interior-
node's ECMP algorithm. In the general case this isn't possible,
but it should be OK for a typical ECMP algorithm which examines:
the source and destination IP addresses and port numbers, the
protocol ID and the DSCP.
The third viewpoint assumes the following:
o Every admission control decision involves probing, using the
signalling set-up message as the probe packet (eg RSVP PATH).
o The PCN-marking behaviour is such that every packet is PCN-marked
if the flow should be blocked, hence only a single probing packet
is needed.
This viewpoint [I-D.draft-babiarz-pcn-3sm] has in particular been
suggested for the scenario where the PCN-domain reaches out towards
the end terminals (note that it's assumed the trust and aggregation
assumptions still hold), although it has also been suggested for
other scenarios.
18. Informative References
[I-D.briscoe-tsvwg-cl-architecture] [I-D.briscoe-tsvwg-cl-architecture]
Briscoe, B., "An edge-to-edge Deployment Model for Pre- Briscoe, B., "An edge-to-edge Deployment Model for Pre-
Congestion Notification: Admission Control over a Congestion Notification: Admission Control over a
DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04
(work in progress), October 2006. (work in progress), October 2006.
[I-D.briscoe-tsvwg-cl-phb] [I-D.briscoe-tsvwg-cl-phb]
Briscoe, B., "Pre-Congestion Notification marking", Briscoe, B., "Pre-Congestion Notification marking",
draft-briscoe-tsvwg-cl-phb-03 (work in progress), draft-briscoe-tsvwg-cl-phb-03 (work in progress),
skipping to change at page 44, line 35 skipping to change at page 47, line 20
Diffserv using Pre-congestion Notification (PCN)", Diffserv using Pre-congestion Notification (PCN)",
draft-lefaucheur-rsvp-ecn-01 (work in progress), draft-lefaucheur-rsvp-ecn-01 (work in progress),
June 2006. June 2006.
[I-D.chan-pcn-problem-statement] [I-D.chan-pcn-problem-statement]
Chan, K., "Pre-Congestion Notification Problem Statement", Chan, K., "Pre-Congestion Notification Problem Statement",
draft-chan-pcn-problem-statement-01 (work in progress), draft-chan-pcn-problem-statement-01 (work in progress),
October 2006. October 2006.
[I-D.ietf-pwe3-congestion-frmwk] [I-D.ietf-pwe3-congestion-frmwk]
Bryant, S., "Pseudowire Congestion Control Framework", "Pseudowire Congestion Control Framework", May 2008, <http
draft-ietf-pwe3-congestion-frmwk-00 (work in progress), ://www.ietf.org/internet-drafts/
February 2007. draft-ietf-pwe3-congestion-frmwk-01.txt>.
[I-D.ietf-tsvwg-admitted-realtime-dscp]
"DSCPs for Capacity-Admitted Traffic", November 2006, <htt
p://www.ietf.org/internet-drafts/
ietf-tsvwg-admitted-realtime-dscp-02.txt>.
[I-D.briscoe-tsvwg-ecn-tunnel] [I-D.briscoe-tsvwg-ecn-tunnel]
"Layered Encapsulation of Congestion Notification", "Layered Encapsulation of Congestion Notification",
June 2007, <http://www.ietf.org/internet-drafts/ July 2008, <http://www.ietf.org/internet-drafts/
briscoe-tsvwg-ecn-tunnel-00.txt>. briscoe-tsvwg-ecn-tunnel-01.txt>.
[I-D.charny-pcn-single-marking] [I-D.charny-pcn-single-marking]
"Pre-Congestion Notification Using Single Marking for "Pre-Congestion Notification Using Single Marking for
Admission and Termination", November 2007, <http:// Admission and Termination", November 2007, <http://
www.ietf.org/internet-drafts/ www.ietf.org/internet-drafts/
draft-charny-pcn-single-marking-03.txt>. draft-charny-pcn-single-marking-03.txt>.
[I-D.eardley-pcn-architecture] [I-D.eardley-pcn-architecture]
"Pre-Congestion Notification Architecture", June 2007, <ht "Pre-Congestion Notification Architecture", June 2007, <ht
tp://www.ietf.org/internet-drafts/ tp://www.ietf.org/internet-drafts/
draft-eardley-pcn-architecture-00.txt>. draft-eardley-pcn-architecture-00.txt>.
[I-D.westberg-pcn-load-control] [I-D.westberg-pcn-load-control]
"LC-PCN: The Load Control PCN Solution", November 2007, <h "LC-PCN: The Load Control PCN Solution", February 2008, <h
ttp://www.ietf.org/internet-drafts/ ttp://www.ietf.org/internet-drafts/
draft-westberg-pcn-load-control-02.txt>. draft-westberg-pcn-load-control-03.txt>.
[I-D.behringer-tsvwg-rsvp-security-groupkeying] [I-D.behringer-tsvwg-rsvp-security-groupkeying]
"Applicability of Keying Methods for RSVP Security", "Applicability of Keying Methods for RSVP Security",
November 2007, <http://www.watersprings.org/pub/id/ November 2007, <http://www.watersprings.org/pub/id/
draft-behringer-tsvwg-rsvp-security-groupkeying-01.txt>. draft-behringer-tsvwg-rsvp-security-groupkeying-01.txt>.
[I-D.briscoe-re-pcn-border-cheat] [I-D.briscoe-re-pcn-border-cheat]
"Emulating Border Flow Policing using Re-ECN on Bulk "Emulating Border Flow Policing using Re-ECN on Bulk
Data", June 2006, <http://www.watersprings.org/pub/id/ Data", February 2008, <http://tools.ietf.org/id/
briscoe-re-pcn-border-cheat-01.txt>. draft-briscoe-re-pcn-border-cheat-01.txt>.
[I-D.draft-babiarz-pcn-3sm] [I-D.draft-babiarz-pcn-3sm]
"Three State PCN Marking", November 2007, <http:// "Three State PCN Marking", November 2007, <http://
www.watersprings.org/pub/id/draft-babiarz-pcn-3sm-01.txt>. www.watersprings.org/pub/id/draft-babiarz-pcn-3sm-01.txt>.
[RFC5129] "Explicit Congestion Marking in MPLS", RFC 5129, [RFC5129] "Explicit Congestion Marking in MPLS", RFC 5129,
January 2008. January 2008.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
skipping to change at page 46, line 37 skipping to change at page 49, line 18
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. December 2002.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002. November 2002.
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006. (OWAMP)", RFC 4656, September 2006.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124,
RFC 4774, November 2006.
[RFC4778] Kaeo, M., "Operational Security Current Practices in [RFC4778] Kaeo, M., "Operational Security Current Practices in
Internet Service Provider Environments", RFC 4778, Internet Service Provider Environments", RFC 4778,
January 2007. January 2007.
[ITU-MLPP] [ITU-MLPP]
"Multilevel Precedence and Pre-emption Service (MLPP)", "Multilevel Precedence and Pre-emption Service (MLPP)",
ITU-T Recommendation I.255.3, 1990. ITU-T Recommendation I.255.3, 1990.
[Iyer] "An approach to alleviate link overload as observed on an [Iyer] "An approach to alleviate link overload as observed on an
IP backbone", IEEE INFOCOM , 2003, IP backbone", IEEE INFOCOM , 2003,
<http://www.ieee-infocom.org/2003/papers/10_04.pdf>. <http://www.ieee-infocom.org/2003/papers/10_04.pdf>.
[Shenker] "Fundamental design issues for the future Internet", IEEE
Journal on selected areas in communications pp 1176 -
1188, Vol 13 (7), 1995.
[Y.1541] "Network Performance Objectives for IP-based Services", [Y.1541] "Network Performance Objectives for IP-based Services",
ITU-T Recommendation Y.1541, February 2006. ITU-T Recommendation Y.1541, February 2006.
[P.800] "Methods for subjective determination of transmission [P.800] "Methods for subjective determination of transmission
quality", ITU-T Recommendation P.800, August 1996. quality", ITU-T Recommendation P.800, August 1996.
[Songhurst] [Songhurst]
"Guaranteed QoS Synthesis for Admission Control with "Guaranteed QoS Synthesis for Admission Control with
Shared Capacity", BT Technical Report TR-CXR9-2006-001, Shared Capacity", BT Technical Report TR-CXR9-2006-001,
Feburary 2006, <http://www.cs.ucl.ac.uk/staff/B.Briscoe/ Feburary 2006, <http://www.cs.ucl.ac.uk/staff/B.Briscoe/
skipping to change at page 47, line 34 skipping to change at page 50, line 19
Menth07-PCN-Config.pdf>. Menth07-PCN-Config.pdf>.
[PCN-email-ECMP] [PCN-email-ECMP]
"Email to PCN WG mailing list", November 2007, <http:// "Email to PCN WG mailing list", November 2007, <http://
www1.ietf.org/mail-archive/web/pcn/current/msg00871.html>. www1.ietf.org/mail-archive/web/pcn/current/msg00871.html>.
[PCN-email-traffic-empty-aggregates] [PCN-email-traffic-empty-aggregates]
"Email to PCN WG mailing list", October 2007, <http:// "Email to PCN WG mailing list", October 2007, <http://
www1.ietf.org/mail-archive/web/pcn/current/msg00831.html>. www1.ietf.org/mail-archive/web/pcn/current/msg00831.html>.
[PCN-email-SRLG]
"Email to PCN WG mailing list", March 2008, <http://
www1.ietf.org/mail-archive/web/pcn/current/msg01359.html>.
[I-D.eardley-pcn-marking-behaviour]
"Marking behaviour of PCN-nodes", June 2008, <http://
www.ietf.org/internet-drafts/
draft-eardley-pcn-marking-behaviour-01.txt>.
[I-D.moncaster-pcn-baseline-encoding]
"Baseline Encoding and Transport of Pre-Congestion
Information", July 2008, <http://www.ietf.org/
internet-drafts/
draft-moncaster-pcn-baseline-encoding-02.txt>.
[I-D.moncaster-pcn-3-state-encoding]
"A three state extended PCN encoding scheme", June 2008, <
http://www.ietf.org/internet-drafts/
draft-moncaster-pcn-3-state-encoding-00.txt>.
[I-D.charny-pcn-comparison]
"Pre-Congestion Notification Using Single Marking for
Admission and Termination", November 2007, <http://
www.watersprings.org/pub/id/
draft-charny-pcn-comparison-00.txt>.
[I-D.tsou-pcn-racf-applic]
"Applicability Statement for the Use of Pre-Congestion
Notification in a Resource-Controlled Network",
February 2008, <http://tools.ietf.org/id/
draft-tsou-pcn-racf-applic-00.txt>.
[I-D.sarker-pcn-ecn-pcn-usecases]
"Usecases and Benefits of end to end ECN support in PCN
Domains", May 2008, <http://tools.ietf.org/id/
draft-sarker-pcn-ecn-pcn-usecases-01.txt>.
[I-D.andersson-mpls-expbits-def]
"MPLS EXP-bits definition", March 2008, <http://
tools.ietf.org/id/
draft-andersson-mpls-expbits-def-00.txt>.
[Menth08] "PCN-Based Admission Control and Flow Termination", 2008,
<http://www3.informatik.uni-wuerzburg.de/staff/menth/
Publications/Menth08-PCN-Comparison.pdf>.
[Hancock] "Slide 14 of 'NSIS: An Outline Framework for QoS
Signalling'", May 2002, <http://www-nrc.nokia.com/sua/
nsis/interim/nsis-framework-outline.ppt>.
Author's Address Author's Address
Philip Eardley Philip Eardley
BT BT
B54/77, Sirius House Adastral Park Martlesham Heath B54/77, Sirius House Adastral Park Martlesham Heath
Ipswich, Suffolk IP5 3RE Ipswich, Suffolk IP5 3RE
United Kingdom United Kingdom
Email: philip.eardley@bt.com Email: philip.eardley@bt.com
 End of changes. 161 change blocks. 
801 lines changed or deleted 993 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/