WDIFF

draft-ietf-pcn-architecture-11.txt --> rfc5559.txt

Congestion and Pre-Congestion Philip. Eardley (Editor)
Notification

Network Working Group P. Eardley, Ed.
Request for Comments: 5559 BT
Internet-Draft April 7, 2009
Intended status:
Category: Informational
Expires: October 9, June 2009

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

Status of this This Memo

This Internet-Draft memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.

This document is submitted subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in full conformance with effect on the
provisions date of BCP 78
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and BCP 79. restrictions with respect to this document.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

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

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

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

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

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

Eardley (Editor) Expires October 9, 2009 [Page 1]

Internet-Draft PCN Architecture April 2009

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Abstract

This document describes a general architecture for flow admission and
termination based on pre-congestion information in order to protect
the quality of service of established established, inelastic flows within a
single Diffserv domain.

Status

Eardley Informational [Page 1]

RFC 5559 PCN Architecture June 2009

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 ....................................................3
1.1. Overview of PCN . . . . . . . . . . . . . . . . . . . . . 4 ............................................3
1.2. Example use case Use Case for PCN . . . . . . . . . . . . . . . . 4 ...................................4
1.3. Applicability of PCN . . . . . . . . . . . . . . . . . . 8 .......................................7
1.4. Documents about PCN . . . . . . . . . . . . . . . . . . . 9 ........................................8
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 .....................................................9
3. High-level functional architecture . . . . . . . . . . . . . . 12 High-Level Functional Architecture .............................11
3.1. Flow admission . . . . . . . . . . . . . . . . . . . . . 14 Admission ............................................13
3.2. Flow termination . . . . . . . . . . . . . . . . . . . . 15 Termination ..........................................14
3.3. Flow admission Admission and/or flow termination when there are
only two Flow Termination When There Are Only
Two PCN encoding states . . . . . . . . . . . . . . 16 Encoding States ...................................15
3.4. Information transport . . . . . . . . . . . . . . . . . . 17 Transport .....................................16
3.5. PCN-traffic . . . . . . . . . . . . . . . . . . . . . . . 17 PCN-Traffic ...............................................16
3.6. Backwards compatibility . . . . . . . . . . . . . . . . . 18 Compatibility ...................................17
4. Detailed Functional architecture . . . . . . . . . . . . . . . 19 Architecture ...............................18
4.1. PCN-interior-node functions . . . . . . . . . . . . . . . 20 PCN-Interior-Node Functions ...............................19
4.2. PCN-ingress-node functions . . . . . . . . . . . . . . . 21 PCN-Ingress-Node Functions ................................19
4.3. PCN-egress-node functions . . . . . . . . . . . . . . . . 22 PCN-Egress-Node Functions .................................20
4.4. Admission control functions . . . . . . . . . . . . . . . 22 Control Functions ...............................21
4.5. Flow termination functions . . . . . . . . . . . . . . . 23 Termination Functions ................................22
4.6. Addressing . . . . . . . . . . . . . . . . . . . . . . . 24 ................................................22
4.7. Tunnelling . . . . . . . . . . . . . . . . . . . . . . . 24 ................................................23
4.8. Fault handling . . . . . . . . . . . . . . . . . . . . . 26 Handling ............................................25
5. Operations and Management . . . . . . . . . . . . . . . . . . 26 ......................................25
5.1. Configuration Fault Operations and Management . . . . . . . . . 27
5.1.1. System options . . . . . . . . . . . . . . . . . . . . 27
5.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . . 28 ...........................25
5.2. Performance & Provisioning Configuration Operations and Management . . 30 ...................26
5.2.1. System Options .....................................27
5.2.2. Parameters .........................................28
5.3. Accounting Operations and Management . . . . . . . . . . 31 ......................30
5.4. Fault Performance and Provisioning Operations and Management . . . . . . . . . . . . . 31

Eardley (Editor) Expires October 9, 2009 [Page 2]

Internet-Draft PCN Architecture April 2009 ....30
5.5. Security Operations and Management . . . . . . . . . . . 32 ........................31
6. Applicability of PCN . . . . . . . . . . . . . . . . . . . . . 33 ...........................................32
6.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . 33 ..................................................32
6.2. Deployment scenarios . . . . . . . . . . . . . . . . . . 35 Scenarios ......................................33
6.3. Assumptions and constraints Constraints on scope . . . . . . . . . . 36 Scope ......................35
6.3.1. Assumption 1: Trust and support Support of PCN -
controlled environment . . . . . . . . . . . . . . . . 37
Controlled Environment .............................36
6.3.2. Assumption 2: Real-time applications . . . . . . . . . 37 Real-Time Applications ...............36
6.3.3. Assumption 3: Many flows Flows and additional load . . . . . 38 Additional Load .......37
6.3.4. Assumption 4: Emergency use out Use Out of scope . . . . . . . 38 Scope ...........37
6.4. Challenges . . . . . . . . . . . . . . . . . . . . . . . 39 ................................................37
7. IANA Security Considerations . . . . . . . . . . . . . . . . . . . . . 41 ........................................40
8. Security considerations . . . . . . . . . . . . . . . . . . . 41
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 42
10. ....................................................41
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
11. Comments Solicited (to be removed by RFC Editor) . . . . . . . 43
12. Changes (to be removed by ...............................................41

Eardley Informational [Page 2]

RFC Editor) . . . . . . . . . . . . 43
12.1. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 43
12.2. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 44
12.3. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 44
12.4. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 44
12.5. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 45
12.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 45
12.7. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 46
12.8. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 46
12.9. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 47
12.10. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 48
12.11. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 49
13. 5559 PCN Architecture June 2009

10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
13.1. ....................................................42
10.1. Normative References . . . . . . . . . . . . . . . . . . 51
13.2. .....................................42
10.2. Informative References . . . . . . . . . . . . . . . . . 51 ...................................42
Appendix A. Possible future work items . . . . . . . . . . . . . 55 Future Work Items ...........................48
A.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 57 .................................................50
A.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 57 ....................................50
A.1.2. Probing functions . . . . . . . . . . . . . . . . . . 58 Functions ...............................50
A.1.3. Discussion of rationale Rationale for probing, its downsides Probing, Its
Downsides and open issues . . . . . . . . . . . . . . . . . . . 58
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 61

Eardley (Editor) Expires October 9, 2009 [Page 3]

Internet-Draft PCN Architecture April 2009 Open Issues .......................51

1. Introduction

1.1. Overview of PCN

The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain, domain
in a simple, scalable scalable, and robust fashion. Two mechanisms are used:
admission control, to decide whether to admit or block a new flow
request, and (in abnormal circumstances) flow termination termination, to decide
whether to terminate some of the existing flows. To achieve this,
the overall rate of PCN traffic PCN-traffic is metered on every link in the
domain, and PCN packets are appropriately marked when certain
configured rates are exceeded. These configured rates are below the
rate of the link link, thus providing notification to boundary nodes about
overloads before any congestion occurs (hence "pre-congestion
notification"). (hence, "Pre-Congestion
Notification"). The level of marking allows boundary nodes to make
decisions about whether to admit or terminate.

Within a PCN-domain, PCN-traffic is forwarded in a prioritised
Diffserv traffic class. Every link in the PCN-domain is configured
with two rates (PCN-threshold-rate and PCN-excess-rate). If the
overall rate of PCN-traffic on a link exceeds a configured rate, then
a PCN-interior-node marks PCN-packets appropriately. The PCN-egress-
nodes use this information to make admission control and flow
termination decisions. Flow admission control determines whether a
new flow can be admitted without any impact, in normal circumstances,
on the QoS of existing PCN-flows. However, in abnormal
circumstances, for instance circumstances
(for instance, a disaster affecting multiple nodes and causing
traffic re-routes, then re-routes), the QoS on existing PCN-flows may degrade even
though care was exercised when admitting those flows. The flow
termination mechanism removes sufficient traffic in order to protect
the QoS of the remaining PCN-flows. All PCN-boundary-nodes and PCN-interior-nodes PCN-
interior-nodes are PCN-enabled and are trusted for correct PCN
operation. PCN-ingress-nodes police arriving packets to check that
they are part of an admitted PCN-flow that keeps within its agreed
flowspec, and hence they maintain per flow per-flow state. PCN-
interior-nodes PCN-interior-nodes
meter all PCN traffic, PCN-traffic, and hence do not need to maintain any per flow per-flow

Eardley Informational [Page 3]

RFC 5559 PCN Architecture June 2009

state. Decisions about flow admission and termination are made for a
particular pair of PCN-boundary-nodes, and hence PCN-egress-nodes
must be able to identify which PCN-ingress-
node PCN-ingress-node sent each PCN-packet.

1.2. Example use case Use Case for PCN

This section outlines an end-to-end QoS scenario that uses the PCN
mechanisms within one domain. The parts outside the PCN-domain are
out of scope for PCN, but are included to help clarify how PCN could
be used. Note that the this section is only an example - -- in particular

Eardley (Editor) Expires October 9, 2009 [Page 4]

Internet-Draft PCN Architecture April 2009 particular,
there are other possibilities (see later) Section 3) for how the PCN-boundary-
nodes PCN-
boundary-nodes perform admission control and flow termination.

As a fundamental building block, each link of the PCN-domain operates
a [PCN08-2] (Figure 1):
the following. Please refer to [Eardley09] and Figure 1.

o Threshold A threshold meter and marker, which marks all PCN-packets if the PCN
traffic
rate of PCN-traffic is greater than a first configured rate, the PCN-
threshold-rate.
PCN-threshold-rate. The admission control mechanism limits the PCN-
traffic
PCN-traffic on each link to *roughly* its PCN-threshold-rate.

o Excess traffic An excess-traffic meter and marker, which marks a proportion of PCN-
packets,
PCN-packets such that the amount marked equals the traffic rate in
excess of a second configured rate, the PCN-excess-rate. The flow
termination mechanism limits the PCN-traffic on each link to
*roughly* its PCN-excess-rate.

Overall

Overall, the aim is to give an "early warning" of potential
congestion before there is any significant build-up of PCN-packets in
the queue on the link; we term this "pre-congestion notification" "Pre-Congestion Notification" by
analogy with ECN (Explicit Congestion Notification, [RFC3168]). Note
that the link only meters the bulk PCN-traffic (and not per flow).

Eardley (Editor) Expires October 9, 2009 Informational [Page 5]

Internet-Draft 4]

RFC 5559 PCN Architecture April June 2009

Figure 1: Example of how the PCN admission control and flow
termination mechanisms operate as the rate of PCN-traffic increases.

The two forms of PCN-marking are indicated by setting of the ECN and
DSCP (Differentiated Services Codepoint [RFC2474]) fields to known
values, which are configured for the domain. Thus Thus, the PCN-egress-
nodes can monitor the PCN-markings in order to measure the severity
of pre-congestion. In addition, the PCN-ingress-nodes need to set
the ECN and DSCP fields to that configured for an unmarked PCN-
packet, and the PCN-egress-nodes need to revert to values appropriate
outside the PCN-domain.

For admission control, we assume end-to-end RSVP signalling (Resource
Reservation Protocol) [RFC2205]) signalling in this example. The
PCN-domain is a single RSVP hop. The PCN-domain operates Diffserv,
and we assume that PCN-traffic is scheduled with the expedited
forwarding (EF) per-
hop behaviour, per-hop behaviour [RFC3246]. Hence Hence, the overall
solution is in line with the "IntServ over Diffserv" framework
defined in [RFC2998], as shown in Figure 2.

Eardley (Editor) Expires October 9, 2009 Informational [Page 6]

Internet-Draft 5]

RFC 5559 PCN Architecture April June 2009

___ ___ _______________________________________ ____ ___
| | | | | PCN- PCN- PCN- | | | | |
| | | | |ingress interior egress| | | | |
| | | | | -node -nodes -node | | | | |
| | | | |-------+ +-------+ +-------+ +------| | | | |
| | | | | | | PCN | | PCN | | | | | | |
| |..| |..|Ingress|..|meter &|..|meter &|..|Egress|..| |..| |
| |..| |..|Policer|..|marker |..|marker |..|Meter |..| |..| |
| | | | |-------+ +-------+ +-------+ +------| | | | |
| | | | | \ / | | | | |
| | | | | \ / | | | | |
| | | | | \ PCN-feedback-information / | | | | |
| | | | | \ (for admission control) / | | | | |
| | | | | --<-----<----<----<-----<-- | | | | |
| | | | | PCN-feedback-information | | | | |
| | | | | (for flow termination) | | | | |
|___| |___| |_______________________________________| |____| |___|

Sx Access PCN-domain Access Rx
End Network Network End
Host Host
<---- signalling across PCN-domain--->
(for admission control & flow termination)

<-------------------end-to-end QoS signalling protocol--------------->

Figure 2: Example of possible overall QoS architecture architecture.

A source wanting to start a new QoS flow sends an RSVP PATH message.
Normal hop-by-hop IntServ [RFC1633] is used outside the PCN-domain
(we assume successfully). The PATH message travels across the PCN-
domain; the PCN-egress-node reads the PHOP (previous RSVP hop) object
to discover the specific PCN-ingress-node for this flow. The RESV
message travels back from the receiver, and triggers the PCN-egress-node PCN-egress-
node to check what fraction of the PCN-traffic, PCN-traffic from the relevant PCN-ingress-node, PCN-
ingress-node is currently being threshold-marked. It adds an object
with this information onto the RESV message, and hence the PCN-ingress-node PCN-
ingress-node learns about the level of pre-congestion on the path.
If this level is below some threshold, then the PCN-ingress-node
admits the new flow into the PCN-domain. The RSVP message triggers
the PCN-ingress-
node PCN-ingress-node to install two normal IntServ items: five-tuple
information, so that it can subsequently identify data packets that
are part of a previously admitted PCN-flow; PCN-flow, and a traffic profile, so
that it can police the flow to within its contract. reservation. Similarly,
the RSVP message triggers the PCN-egress-node to install five-tuple
and PHOP
information, information so that it can identify packets as part of a
flow from a specific PCN-ingress-node.

Eardley (Editor) Expires October 9, 2009 Informational [Page 7]

Internet-Draft 6]

RFC 5559 PCN Architecture April June 2009

The flow termination mechanism may happen when some abnormal
circumstances
circumstance causes a link to become so pre-congested that it
excess-traffic-marks excess-
traffic-marks (and perhaps also drops) PCN-packets. In this example,
when a PCN-egress-node observes such a packet packet, it then, with some
probability, terminates this PCN-flow; the probability is configured
low enough to avoid over-termination over termination and high enough to ensure rapid
termination of enough flows. It also informs the relevant PCN-ingress-node, PCN-
ingress-node so that it can block any further traffic on the
terminated flow.

1.3. Applicability of PCN

Compared with alternative QoS mechanisms, PCN has certain advantages
and disadvantages that will make it appropriate in particular
scenarios. For example, compared with hop-by-hop IntServ [RFC1633],
PCN only requires per flow per-flow state at the PCN-ingress-nodes. Compared
with the Diffserv architecture [RFC2475], an operator needs to be
less accurate and/or conservative in its prediction of the traffic
matrix. The Diffserv architecture's traffic conditioning traffic-conditioning agreements
are static and coarse; they are defined at subscription time, time and
they are
used (for instance) to limit the total traffic at each ingress of the domain
domain, regardless of the egress for the traffic. On the other hand,
PCN firstly uses admission control based on measurements of the
current conditions between the specific pair of PCN-boundary-nodes,
and secondly, in case of a disaster, PCN protects the QoS of most
flows by terminating a few selected ones.

PCN's admission control is a measurement-based mechanism. Hence Hence, it
assumes that the present is a reasonable prediction of the future:
the network conditions are measured at the time of a new flow
request, but the actual network performance must be acceptable during
the call some time later. Hence Hence, PCN is unsuitable in several
circumstances:

o If the source adapts its bit rate dependent on the level of pre-
congestion, because then the aggregate traffic might become
unstable. The assumption in this document is that PCN-packets
come from real time real-time applications generating inelastic traffic,
such as the Controlled Load Service, Service [RFC2211].

o If a potential bottleneck link has capacity for only a few flows,
because then a new flow can move a link directly from no pre-
congestion to being so overloaded that it has to drop packets.
The assumption in this document is that this isn't a problem.

o If there is the danger of a "flash crowd" crowd", in which many admission
requests arrive within the reaction time of PCN's admission
mechanism, because then they all might get admitted and so

Eardley (Editor) Expires October 9, 2009 Informational [Page 8]

Internet-Draft 7]

RFC 5559 PCN Architecture April June 2009

overload the network. The assumption in this document is that, if
it is necessary, then flash crowds are limited in some fashion
beyond the scope of this document, for instance by rate limiting rate-limiting
QoS requests.

The applicability of PCN is discussed further in Section 6.

1.4. Documents about PCN

The purpose of this document is to describe a general architecture
for flow admission and termination based on (pre-) congestion (pre-)congestion
information in order to protect the quality of service of flows
within a Diffserv domain. This document describes the PCN
architecture at a high level (Section 3) and in more detail
(Section 4). It also defines some terminology, and provides
considerations about
operations and operations, management, and security. Section 6
considers the applicability of PCN in more detail, covering its
benefits, deployment scenarios, assumptions assumptions, and potential
challenges. The Appendix covers some potential future work items.

Aspects of PCN are also documented elsewhere:

o Metering and marking: [PCN08-2] [Eardley09] standardises threshold metering
and marking, marking and excess traffic excess-traffic metering and marking. A PCN-
packet PCN-packet
may be marked, depending on the metering results.

o Encoding: the "baseline" encoding is described in [PCN08-1], [Moncaster09-1],
which standardises two PCN encoding states (PCN-marked and not PCN-
marked),
PCN-marked), whilst (experimental) extensions to the baseline
encoding can provide three encoding states (threshold-marked, excess-
traffic-marked, not PCN-marked,
excess-traffic-marked, or perhaps not PCN-marked), for instance, see
[Moncaster09-2]. (There may be further encoding states as
suggested in [Westberg08]). [Westberg08].) Section 3.6 considers the backwards
compatability
compatibility of PCN encoding with ECN.

o PCN-boundary-node behaviour: how the PCN-boundary-nodes convert
the PCN-markings into decisions about flow admission and flow
termination, as described in Informational documents. documents such as
[Taylor09] and [Charny07-2]. The concept is that the standardised
metering and marking by PCN-nodes allows several possible PCN-boundary-node PCN-
boundary-node behaviours. A number of possibilities are outlined
in this document; detailed descriptions and comparisons are in
[Charny07-1] and [Menth08-3]. [Menth09-2].

o Signalling between PCN-boundary-nodes: Signalling signalling is needed to
transport PCN-feedback-information between the PCN-boundary-nodes
(in the example above, this is the fraction of traffic, between
the pair of PCN-boundary-nodes, that is PCN-marked). The exact

Eardley Informational [Page 8]

RFC 5559 PCN Architecture June 2009

details vary for different PCN-boundary-node behaviours, and so
should be described in those documents. It may require an

Eardley (Editor) Expires October 9, 2009 [Page 9]

Internet-Draft PCN Architecture April 2009
extension to the signalling protocol - -- standardisation is out of
scope of the PCN WG.

o The interface by which the PCN-boundary-nodes learn identification
information about the admitted flows: the exact requirements vary
for different PCN-boundary-node behaviours and for different
signalling protocols, and so should be described in those
documents. They will be similar to those described in the example
above - -- a PCN-ingress-node needs to be able to identify that a
packet is part of a previously admitted flow (typically from its
five-tuple) and each PCN-boundary-node needs to be able to
identify the other PCN-boundary-node for the flow.

2. Terminology

o PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled
nodes that perform Diffserv scheduling [RFC2474]; the complete set
of PCN-nodes that in principle can, through PCN-marking packets,
influence decisions about flow admission and termination for the
PCN-domain; the PCN-domain includes the PCN-egress-nodes, which measure these
PCN-marks, and the PCN-ingress-nodes.

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. 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 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) [RFC2474]. The
PCN-BA uses the PCN mechanisms to carry PCN-traffic 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.

Eardley Informational [Page 9]

RFC 5559 PCN Architecture June 2009

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 [RFC2474]) or some identifiable collection of
microflows.

Eardley (Editor) Expires October 9, 2009 [Page 10]

Internet-Draft PCN Architecture April 2009

o Pre-congestion: a condition of a link within a PCN-domain such
that the PCN-node performs PCN-marking, in order to provide an
"early warning" of potential congestion before there is any
significant build-up of PCN-packets in the real queue. (Hence, by
analogy with ECN ECN, we call our mechanism Pre-Congestion
Notification.)

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-threshold-rate: a reference rate configured for each link in
the PCN-domain, which is lower than the PCN-excess-rate. It is
used by a metering behaviour that determines whether Such a packet
should be PCN-marked with a first encoding, "threshold-marked". is
then called PCN-marked.

o Threshold-metering: a metering behaviour that, if the PCN-traffic
exceeds the PCN-threshold-rate, indicates that all PCN-traffic is
to be threshold-marked.

o PCN-threshold-rate: the reference rate of a threshold-meter, which
is configured for each link in the PCN-domain and which is lower
than the PCN-excess-rate.

o Threshold-marking: the setting of the header in a PCN-packet to a
specific encoding, based on indications from the threshold-meter.

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 metering behaviour that determines whether
Such a packet
should be PCN-marked with a second encoding, "excess-traffic-
marked". is then called threshold-marked.

o Excess-traffic-metering: a metering behaviour that, if the PCN-
traffic exceeds the PCN-excess-rate, indicates that the amount of
PCN-traffic to be PCN-marked excess-traffic-marked is equal to the amount in
excess of the PCN-excess-rate.

o PCN-excess-rate: the reference rate of an excess-traffic-meter,
which is a configured for each link in the PCN-domain and which is
higher than the PCN-threshold-rate.

o Excess-traffic-marking: the setting of the header in a PCN-packet
to a specific encoding, based on indications from the excess-
traffic-meter. Such a packet is then called excess-traffic-
marked.

o PCN-colouring: the process of setting the header in a PCN-packet
by a PCN-boundary-node; performed by a PCN-ingress-node so that
PCN-nodes can easily identify PCN-packets; performed by a PCN-
egress-node so that the header is appropriate for nodes beyond the
PCN-domain.

Eardley Informational [Page 10]

RFC 5559 PCN Architecture June 2009

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.

Eardley (Editor) Expires October 9, 2009 [Page 11]

Internet-Draft PCN Architecture April 2009

o PCN-feedback-information: information signalled by a PCN-egress-
node to a PCN-ingress-node (or a central control node), which is
needed for the flow admission and flow termination mechanisms.

o PCN-admissible-rate: the rate of PCN-traffic on a link up to which
PCN admission control should accept new PCN-flows.

o PCN-supportable-rate: the rate of PCN-traffic on a link down to
which PCN flow termination should, if necessary, terminate already
admitted PCN-flows.

3. High-level functional architecture High-Level Functional Architecture

The high-level approach is to split functionality between:

o PCN-interior-nodes 'inside' "inside" the PCN-domain, which monitor their
own state of pre-congestion and mark PCN-packets as appropriate.
They are not flow-aware, nor are they aware of ingress-egress-aggregates. ingress-egress-
aggregates. The functionality is also done by PCN-ingress-nodes
for their outgoing interfaces (ie (ie, those 'inside' "inside" the PCN-domain).

o PCN-boundary-nodes at the edge of the PCN-domain, which control
admission of new PCN-flows and termination of existing PCN-flows,
based on information from PCN-interior-nodes. This information is
in the form of the PCN-marked data packets (which are intercepted
by the PCN-egress-nodes) and is not in signalling messages. Generally
Generally, PCN-ingress-nodes are flow-aware.

The aim of this split is to keep the bulk of the network simple,
scalable
scalable, and robust, whilst confining policy, application-level application-level, and
security interactions to the edge of the PCN-domain. For example example,
the lack of flow awareness means that the PCN-interior-nodes don't
care about the flow information associated with PCN-packets, nor do
the PCN-boundary-nodes care about which PCN-interior-nodes its ingress-
egress-aggregates
ingress-egress-aggregates traverse.

In order to generate information about the current state of the PCN-
domain, each PCN-node PCN-marks packets if it is "pre-congested".
Exactly when a PCN-node decides if it is "pre-congested" (the
algorithm) and exactly how packets are "PCN-marked" (the encoding)
will be defined in separate standards-track Standards Track documents, but at a high
level it is as follows:

Eardley Informational [Page 11]

RFC 5559 PCN Architecture June 2009

o the algorithms: a PCN-node meters the amount of PCN-traffic on
each one of its outgoing (or incoming) links. The measurement is
made as an aggregate of all PCN-packets, and not per flow. There are
two algorithms, algorithms: one for threshold-metering and one for excess-

Eardley (Editor) Expires October 9, 2009 [Page 12]

Internet-Draft PCN Architecture April 2009
traffic-metering. The meters trigger PCN-marking as necessary.

o the encoding(s): a PCN-node PCN-marks a PCN-packet by modifying a
combination of the DSCP and ECN fields. In the "baseline"
encoding [PCN08-1], [Moncaster09-1], the ECN field is set to 11 and the DSCP
is not altered. Extension encodings may be defined that, at most,
use a second DSCP (eg (eg, as in [Moncaster08]) [Moncaster09-2]) and/or set the ECN
field to values other than 11 (eg (eg, as in [Menth08-2]).

In a PCN-domain PCN-domain, the operator may have two or three encoding states
available. The baseline encoding provides two encoding states (not
PCN-marked,
PCN-marked and PCN-marked), whilst extended encodings can provide
three encoding states (not PCN-marked, threshold-marked, excess-traffic-
marked). and excess-
traffic-marked).

An operator may choose to deploy either admission control or flow
termination or both. Although designed to work together, they are
independent mechanisms, and the use of one does not require or
prevent the use of the other. Three encoding states naturally allows
both flow admission and flow termination. If there are only two
encoding states, then there are several options - -- see Section 3.3.

The PCN-boundary-nodes monitor the PCN-marked packets in order to
extract information about the current state of the PCN-domain. Based
on this monitoring, a distributed decision is made about whether to
admit a prospective new flow or whether to terminate existing flow(s). Sections
4.4 and 4.5 mention various possibilities for how the functionality
could be distributed.

PCN-metering and PCN-marking needs need to be configured on all
(potentially pre-congested) links in the PCN-domain to ensure that
the PCN mechanisms protect all links. The actual functionality can
be configured on the outgoing or incoming interfaces of PCN-nodes - --
or one algorithm could be configured on the outgoing interface and
the other on the incoming interface. The important point is that a
consistent choice is made across the PCN-domain to ensure that the
PCN mechanisms protect all links. See [PCN08-2] [Eardley09] for further
discussion.

The objective of threshold-marking, as triggerd triggered by the threshold-
metering algorithm, is to threshold-mark all PCN-packets whenever the
bit rate of PCN-packets is greater than some configured rate, the PCN-
threshold-rate.
PCN-threshold-rate. The objective of excess-traffic-metering, as
triggered by the excess-traffic-marking algorithm, is to excess-

Eardley Informational [Page 12]

RFC 5559 PCN Architecture June 2009

traffic-mark PCN-packets at a rate equal to the difference between
the bit rate of PCN-packets and some configured rate, the PCN-excess-
rate. Note that this description reflects the overall intent of the
algorithms rather than their instantaneous behaviour, since the rate

Eardley (Editor) Expires October 9, 2009 [Page 13]

Internet-Draft PCN Architecture April 2009
measured at a particular moment depends on the detailed algorithm,
its implementation, and the traffic's variance as well as its rate
(eg
(eg, marking may well continue after a recent overload overload, even after
the instantaneous rate has dropped). The algorithms are specified in
[PCN08-2].
[Eardley09].

Admission and termination approaches are detailed and compared in
[Charny07-1] and [Menth08-3]. [Menth09-2]. The discussion below is just a brief
summary. Sections 3.1 and 3.2 assume there are three encoding states
available, whilst Section 3.3 assumes there are two encoding states
available.

From the perspective of the outside world, a PCN-domain essentially
looks like a Diffserv domain, but without the Diffserv architecture's
traffic conditioning
traffic-conditioning agreements. PCN-traffic is either transported
across it transparently or policed at the PCN-ingress-node (ie (ie,
dropped or carried at a lower QoS). One difference is that PCN-
traffic has better QoS guarantees than normal Diffserv traffic, traffic
because the PCN mechanisms better protect the QoS of admitted flows.
Another difference may occur in the rare circumstance when there is a
failure: on the one hand hand, some PCN-flows may get terminated, but terminated but, on
the other hand hand, other flows will get their QoS restored. Non PCN- Non-PCN-
traffic is treated transparently, ie ie, the PCN-domain is a normal
Diffserv domain.

3.1. Flow admission Admission

The objective of PCN's flow admission control mechanism is to limit
the PCN-traffic on each link in the PCN-domain to *roughly* its PCN-
admissible-rate,
admissible-rate by admitting or blocking prospective new flows, in
order to protect the QoS of existing PCN-flows. With three encoding
states available, the PCN-threshold-rate is configured by the
operator as equal to the PCN-admissible-rate on each link. It is set
lower than the traffic rate at which the link becomes congested and
the node drops packets.

Exactly how the admission control decision is made will be defined
separately in informational Informational documents. This document describes two
approaches (others might be possible):

o the The PCN-egress-node measures (possibly as a moving average) the
fraction of the PCN-traffic that is threshold-marked. The
fraction is measured for a specific ingress-egress-aggregate. If
the fraction is below a threshold value value, then the new flow is
admitted, and

Eardley Informational [Page 13]

RFC 5559 PCN Architecture June 2009

admitted; if the fraction is above the threshold value value, then it is
blocked. The fraction could be measured as an EWMA (exponentially
weighted moving average), which has sometimes been called the
"congestion level estimate".

Eardley (Editor) Expires October 9, 2009 [Page 14]

Internet-Draft PCN Architecture April 2009

o the The PCN-egress-node monitors PCN-traffic and if it receives one
(or several) threshold-marked packets, then the new flow is
blocked, otherwise
blocked; otherwise, it is admitted. One possibility may be to
react to the marking state of an initial flow set-up flow-setup packet (eg (eg,
RSVP PATH). Another is that after one (or several) threshold-
marks then
marks, all flows are blocked until after a specific period of no
congestion.

Note that the admission control decision is made for a particular
pair of PCN-boundary-nodes. So it is quite possible for a new flow
to be admitted between one pair of PCN-boundary-nodes, whilst at the
same time another admission request is blocked between a different
pair of PCN-boundary-nodes.

3.2. Flow termination Termination

The objective of PCN's flow termination mechanism is to limit the
PCN-traffic on each link to *roughly* its PCN-supportable-rate, by
terminating some existing PCN-flows, in order to protect the QoS of
the remaining PCN-flows. With three encoding states available, the
PCN-excess-rate is configured by the operator as equal to the PCN-
supportable-rate on each link. It may be set lower than the traffic
rate at which the link becomes congested and at which the node drops
packets.

Exactly how the flow termination decision is made will be defined
separately in informational Informational documents. This document describes
several approaches (others might be possible):

o In one approach approach, the PCN-egress-node measures the rate of PCN-
traffic that is not excess-traffic-marked, which is the amount of
PCN-traffic that can actually be supported, and communicates this
to the PCN-ingress-node. Also Also, the PCN-ingress-node measures the
rate of PCN-traffic that is destined for this specific PCN-egress-
node. The difference represents the excess amount that should be
terminated.

o Another approach instead measures the rate of excess-traffic-
marked traffic and terminates this amount of traffic. This
terminates less traffic than the previous bullet approach, if some nodes
are dropping PCN-traffic.

Eardley Informational [Page 14]

RFC 5559 PCN Architecture June 2009

o Another approach monitors PCN-packets and terminates some of the
PCN-flows that have an excess-traffic-marked packet. (If all such
flows were terminated, far too much traffic would be terminated,
so a random selection needs to be made from those with an excess-
traffic-marked packet, packet [Menth08-1].)

Since flow termination is designed for "abnormal" circumstances, it

Eardley (Editor) Expires October 9, 2009 [Page 15]

Internet-Draft PCN Architecture April 2009
is quite likely that some PCN-nodes are congested and hence and, hence, that
packets are being dropped and/or significantly queued. The flow
termination mechanism must accommodate this.

Note also that the termination control decision is made for a
particular pair of PCN-boundary-nodes. So it is quite possible for
PCN-flows to be terminated between one pair of PCN-boundary-nodes,
whilst at the same time none are terminated between a different pair
of PCN-boundary-nodes.

3.3. Flow admission Admission and/or flow termination when there are only two Flow Termination When There Are Only Two PCN
encoding states
Encoding States

If a PCN-domain has only two encoding states available (PCN-marked
and not PCN-marked), ie ie, it is using the baseline encoding [PCN08-1],
[Moncaster09-1], then an operator has three options (others might be
possible):

o admission control only: PCN-marking means threshold-marking, ie ie,
only the threshold-metering algorithm triggers PCN-marking. Only
PCN admission control is available.

o flow termination only: PCN-marking means excess-traffic-marking,
ie
ie, only the excess-traffic-metering algorithm triggers PCN-
marking. Only PCN termination control is available.

o both admission control and flow termination: only the excess-
traffic-metering algorithm triggers PCN-marking, however PCN-marking; however, the
configured rate (PCN-excess-rate) is set equal to the PCN-
admissible-rate, as shown in Figure 3. [Charny07-2] 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.

Eardley (Editor) Expires October 9, 2009 Informational [Page 16]

Internet-Draft 15]

RFC 5559 PCN Architecture April June 2009

Figure 3: Schematic of how the PCN admission control and flow
termination mechanisms operate as the rate of PCN-traffic increases,
for a PCN-domain with two encoding states and using the approach of
[Charny07-2]. Note: U is a global parameter for all links in the
PCN-domain.

3.4. Information transport Transport

The transport of pre-congestion information from a PCN-node to a PCN-
egress-node is through PCN-markings in data packet headers, ie ie, "in-
band":
band"; no signalling protocol messaging is needed. Signalling is
needed to transport PCN-feedback-information, PCN-feedback-information -- for example example, to
convey the fraction of PCN-marked traffic from a PCN-egress-node to
the relevant PCN-ingress-node. Exactly what information needs to be
transported will be described in future documents about possible
boundary mechanisms. The signalling could be done by an extension of
RSVP or NSIS, NSIS (Next Steps in Signalling), for instance; [Lefaucheur06]
describes the extensions needed for RSVP.

3.5. PCN-traffic PCN-Traffic

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
from other traffic. This is through a combination of the DSCP
field and/or ECN field.

Eardley (Editor) Expires October 9, 2009 Informational [Page 17]

Internet-Draft 16]

RFC 5559 PCN Architecture April June 2009

o It is not advised to have non PCN-traffic that competes for the
same capacity as PCN-traffic competing-non-PCN-traffic but, if there
is such traffic, there needs to be a mechanism to limit it. "Capacity" means the
forwarding bandwidth on a link; "competes"
"Competing-non-PCN-traffic" means traffic that non PCN-
packets will delay PCN-packets in the queue shares a link with
PCN-traffic and competes for the link. Hence its forwarding bandwidth. Hence,
more non PCN-traffic competing-non-PCN-traffic results in poorer QoS for PCN.
Further, the unpredictable amount of non PCN-traffic competing-non-PCN-traffic
makes the PCN mechanisms less accurate and so reduces PCN's
ability to protect the QoS of admitted PCN-flows PCN-flows.

o Two examples of such non PCN-traffic (ie that competes for the
same capacity as PCN-traffic) competing-non-PCN-traffic are:

1. traffic that is priority scheduled over PCN (perhaps a
particular application or an operator's control messages). messages);

2. traffic that is scheduled at the same priority as PCN (for
example
example, if the Voice-Admit codepoint is used for PCN-traffic
[PCN08-1]
[Moncaster09-1] and there is non-PCN non-PCN, voice-admit traffic in
the PCN-
domain). PCN-domain).

o If there is such non PCN-traffic (ie that competes for the same
capacity as PCN-traffic), competing-non-PCN-traffic, then PCN's mechanisms
should take account of it, in order to improve the accuracy of the
decision about whether to admit (or terminate) a PCN-flow. For
example, one mechanism is that such non PCN-traffic competing-non-PCN-traffic
contributes to the PCN
meters (ie PCN-meters (ie, is metered by the threshold-marking and excess-traffic- threshold-
marking and excess-traffic-marking algorithms).

o There will be non PCN-traffic other non-PCN-traffic that doesn't compete for the
same
capacity forwarding bandwidth as PCN-traffic, because it is forwarded
at lower priority. Hence Hence, it shouldn't contribute to the PCN PCN-
meters. Examples are best effort best-effort and assured forwarding assured-forwarding traffic.
However, a PCN-node should dedicate some capacity to lower lower-
priority traffic so that it isn't starved.

o The This document assumes that the PCN mechanisms are applied to a
single behaviour aggregate in the PCN-domain. However, it would
also be possible to apply them independently to more than one
behaviour aggregate, which are distinguished by DSCP.

3.6. Backwards compatibility Compatibility

PCN specifies semantics for the ECN field that differ from the
default semantics of [RFC3168]. A particular PCN encoding scheme
needs to describe how it meets the guidelines of BCP 124 [RFC4774]
for specifying alternative semantics for the ECN field. In summary summary,
the approach is to:

Eardley (Editor) Expires October 9, 2009 [Page 18]

Internet-Draft PCN Architecture April 2009

o use a DSCP to allow PCN-nodes to distinguish PCN-traffic that uses
the alternative ECN semantics;

Eardley Informational [Page 17]

RFC 5559 PCN Architecture June 2009

o define these semantics for use within a controlled region, the
PCN-domain;

o take appropriate action if ECN capable, non-PCN traffic ECN-capable, non-PCN-traffic arrives at
a PCN-ingress-node with the DSCP used by PCN.

For the baseline encoding [PCN08-1], [Moncaster09-1], the 'appropriate action' "appropriate action"
is to block ECN-capable traffic that uses the same DSCP as PCN from
entering the PCN-domain directly. Blocking "Blocking" means it is dropped or
downgraded to a lower priority lower-priority behaviour aggregate, or alternatively
such traffic may be tunnelled through the PCN-domain. The reason
that 'appropriate action' "appropriate action" is needed is that the PCN-egress-node
clears the ECN field to 00.

Extended encoding schemes may need to take different 'appropriate
action'. "appropriate
action".

4. Detailed Functional architecture Architecture

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

1. functions needed at PCN-interior-nodes

2. functions needed at PCN-ingress-nodes

3. functions needed at PCN-egress-nodes

4. other functions needed for flow admission control

5. other functions needed for flow termination control

Note: Probing is covered in the Appendix.

The section then discusses some other detailed topics:

Eardley (Editor) Expires October 9, 2009 [Page 19]

Internet-Draft PCN Architecture April 2009

1. addressing

2. tunnelling

3. fault handling

Eardley Informational [Page 18]

RFC 5559 PCN Architecture June 2009

4.1. PCN-interior-node functions PCN-Interior-Node Functions

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

o Behaviour aggregate classification - determine whether or not an
incoming packet is a PCN-packet or not. PCN-packet.

o PCN-meter - measure the 'amount "amount of PCN-traffic'. PCN-traffic". The measurement
is made on the overall PCN-traffic, and not per flow. Algorithms
determine whether to indicate to the PCN-marking functionality
that packets should be PCN-marked.

o PCN-mark - as triggered by indications from the PCN-meter
functionality,
functionality; if necessary necessary, PCN-mark packets wth with the appropiate appropriate
encoding.

o Drop - if the queue overflows overflows, then naturally packets are dropped.
In addition, the link may be configured with a maximum rate for
PCN-traffic (below the physical link rate), above which PCN-
packets are dropped.

The functions are defined in [PCN08-2] [Eardley09] and the baseline encoding in
[PCN08-1]
[Moncaster09-1] (extended encodings are to be defined in other
documents).

Eardley (Editor) Expires October 9, 2009 [Page 20]

Internet-Draft PCN Architecture April 2009

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

Figure 4: Schematic of PCN-interior-node functionality functionality.

4.2. PCN-ingress-node functions PCN-Ingress-Node Functions

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

Eardley Informational [Page 19]

RFC 5559 PCN Architecture June 2009

o Packet classification - determine whether an incoming packet is
part of a previously admitted flow, flow by using a filter spec (eg (eg,
DSCP, source and destination addresses, port numbers, and
protocol).

o Police - police, by dropping, dropping any packets received with a DSCP
indicating PCN transport that do not belong to an admitted flow.
(A prospective PCN-flow that is rejected could be blocked or
admitted into a lower priority lower-priority behaviour aggregate.) Similarly,
police packets that are part of a previously admitted flow, to
check that the flow keeps to the agreed rate or flowspec (eg (eg, see
[RFC1633] for a microflow and its NSIS equivalent).

o PCN-colour - set the DSCP and ECN fields appropriately for the
PCN-domain, for example example, as in [PCN08-1]. [Moncaster09-1].

o Meter - some approaches to flow termination require the PCN-
ingress-node to measure the (aggregate) rate of PCN-traffic
towards a particular PCN-egress-node.

The first two are policing functions, needed to make sure that PCN-
packets admitted into the PCN-domain belong to a flow that has been
admitted and to ensure that the flow keeps to the flowspec agreed (eg
(eg, doesn't exceed an agreed maximum rate and is inelastic traffic).
Installing the filter spec will typically be done by the signalling
protocol, as will re-installing the filter, for example example, after a re-

Eardley (Editor) Expires October 9, 2009 [Page 21]

Internet-Draft PCN Architecture April 2009
route that changes the PCN-ingress-node (see [Briscoe06] for an
example using RSVP). PCN-colouring allows the rest of the PCN-domain
to recognise PCN-packets.

4.3. PCN-egress-node functions PCN-Egress-Node Functions

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

o Packet classify - determine which PCN-ingress-node a PCN-packet
has come from.

o Meter - "measure PCN-traffic" or "monitor PCN-marks".

o PCN-colour - for PCN-packets, set the DSCP and ECN fields to the
appropriate values for use outside the PCN-domain.

The metering functionality functionality, of course course, depends on whether it is
targeted at admission control or flow termination. Alternatives
involve the PCN-egress-node "measuring" "measuring", as an aggregate (ie (ie, not per
flow)
flow), all PCN-packets from a particular PCN-ingress-node, or
"monitoring" the PCN-traffic and reacting to one (or several) PCN-

Eardley Informational [Page 20]

RFC 5559 PCN Architecture June 2009

marked packets. For PCN-colouring, [PCN08-1] [Moncaster09-1] specifies that
the PCN-
egress-node re-sets PCN-egress-node resets the ECN field to 00; other encodings may
define different behaviour.

4.4. Admission control functions Control Functions

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

o Make decision about admission - based on the output of the PCN-
egress-node's meter function. In the case where it "measures PCN-
traffic", the measured traffic on the ingress-egress-aggregate is
compared with some reference level. In the case where it
"monitors PCN-marks", then the decision is based on whether or not one
(or several) packets is (are) are PCN-marked or not (eg (eg, the RSVP PATH message).
In either case, the admission decision also takes account of
policy and application layer application-layer requirements [RFC2753].

o Communicate decision about admission - signal the decision to the
node making the admission control request (which may be outside
the PCN-domain), PCN-domain) and to the policer (PCN-ingress-node function) for
enforcement of the decision.

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

Eardley (Editor) Expires October 9, 2009 [Page 22]

Internet-Draft PCN Architecture April 2009

o The decision is made at the PCN-egress-node and the decision
(admit or block) is signalled to the PCN-ingress-node.

o The decision is recommended by the PCN-egress-node (admit or
block)
block), but the decision is definitively made by the PCN-ingress-
node. The rationale is that the PCN-egress-node naturally has the
necessary information about the amount of PCN-marks on the
ingress-egress-aggregate, but whereas the PCN-ingress-node is the
policy enforcement point [RFC2753], which [RFC2753] that polices incoming traffic
to ensure it is part of an admitted PCN-flow.

o The decision is made at the PCN-ingress-node, which requires that
the PCN-egress-node signals PCN-feedback-information to the PCN-
ingress-node. For example, it could signal the current fraction
of PCN-traffic that is PCN-marked.

o The decision is made at a centralised node (see Appendix).

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

Eardley Informational [Page 21]

RFC 5559 PCN Architecture June 2009

4.5. Flow termination functions Termination Functions

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

o PCN-meter at PCN-egress-node - similarly to flow admission, there
are two types of possibilities: to "measure PCN-traffic" on the
ingress-egress-aggregate, and or to "monitor PCN-marks" and react to
one (or several) PCN-marks.

o (if required) PCN-meter at PCN-ingress-node - make "measurements
of PCN-traffic" being sent towards a particular PCN-egress-node;
again, this is done for the ingress-egress-aggregate and not per
flow.

o (if required) Communicate PCN-feedback-information to the node
that makes the flow termination decision. For decision - for example, as in
[Briscoe06], communicate the PCN-egress-node's measurements to the
PCN-ingress-node.

o Make decision about flow termination - use the information from
the PCN-meter(s) to decide which PCN-flow or PCN-flows to
terminate. The decision takes account of policy and application application-
layer requirements [RFC2753].

o Communicate decision about flow termination - signal the decision
to the node that is able to terminate the flow (which may be

Eardley (Editor) Expires October 9, 2009 [Page 23]

Internet-Draft PCN Architecture April 2009
outside the PCN-domain), PCN-domain) and to the policer (PCN-ingress-node
function) for enforcement of the decision.

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

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

4.6. Addressing

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

The

At a minimum, the PCN-egress-node needs to know the address of the
PCN-ingress-node associated with a flow, at a minimum flow so that the PCN-ingress-node
can be informed to enforce of the admission decision (and any flow termination
decision) and enforce it through policing. There are various

Eardley Informational [Page 22]

RFC 5559 PCN Architecture June 2009

possibilities for how the PCN-egress-node can do this, ie ie, associate
the received packet to the correct ingress-egress-aggregate. It is
not the intention of this document to mandate a particular mechanism.

o The addressing information can be gathered from signalling. For signalling -- for
example, through the regular processing of an RSVP PATH message,
as the PCN-
ingress-node PCN-ingress-node is the previous RSVP hop (PHOP)
([Lefaucheur06]). Or Another option is that the PCN-ingress-node
could signal its address to the PCN-egress-
node. PCN-egress-node.

o Always tunnel PCN-traffic across the PCN-domain. Then the PCN-
ingress-node's address is simply the source address of the outer
packet header. The PCN-ingress-node needs to learn the address of
the PCN-egress-node, either by manual configuration or by one of
the automated tunnel endpoint discovery mechanisms (such as
signalling or probing over the data route, interrogating routing routing,
or using a centralised broker).

4.7. Tunnelling

Tunnels may originate and/or terminate within a PCN-domain (eg (eg, IP
over IP, IP over MPLS). It is important that the PCN-marking of any
packet can potentially influence PCN's flow admission control and
termination - -- it shouldn't matter whether the packet happens to be
tunnelled at the PCN-node that PCN-marks the packet, or indeed
whether it's decapsulated or encapsulated by a subsequent PCN-node.
This suggests that the "uniform conceptual model" described in

Eardley (Editor) Expires October 9, 2009 [Page 24]

Internet-Draft PCN Architecture April 2009
[RFC2983] should be re-applied in the PCN context. In line with both
this and the approach of [RFC4303] and [Briscoe08-2], [Briscoe09], the following
rule is applied if encapsulation is done within the PCN-domain:

o any Any PCN-marking is copied into the outer header header.

Note: A tunnel will not provide this behaviour if it complies with
[RFC3168] tunnelling in either mode, but it will if it complies with
[RFC4301] IPSec IPsec tunnelling.

Similarly, in line with the "uniform conceptual model" of [RFC2983],
with the "full-functionality option" of [RFC3168], and with
[RFC4301], the following rule is applied if decapsulation is done
within the PCN-
domain: PCN-domain:

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

Note:

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

Eardley Informational [Page 23]

RFC 5559 PCN Architecture June 2009

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

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

1. The tunnel originates outside a PCN-domain and ends inside it.
If the packet arrives at the tunnel ingress with the same
encoding as used within the PCN-domain to indicate PCN-marking,
then this could lead the PCN-egress-node to falsely measure pre-
congestion.

2. The tunnel originates inside a PCN-domain and ends outside it.
If the packet arrives at the tunnel ingress already PCN-marked,
then it will still have the same encoding when it's decapsulated decapsulated,
which could potentially confuse nodes beyond the tunnel egress.

Eardley (Editor) Expires October 9, 2009 [Page 25]

Internet-Draft PCN Architecture April 2009

In line with the solution for partially capable Diffserv tunnels in
[RFC2983], the following rules are applied:

o For case (1), the tunnel egress node clears any PCN-marking on the
inner header. This rule is applied before the 'copy "copy on
decapsulation'
decapsulation" rule above.

o For case (2), the tunnel ingress node clears any PCN-marking on
the inner header. This rule is applied after the 'copy "copy on
encapsulation'
encapsulation" rule above.

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

Tunnelling constraints were a major factor in the choice of the
baseline encoding. As explained in [PCN08-1], [Moncaster09-1], with current
tunnelling endpoints endpoints, only the 11 codepoint of the ECN field survives
decapsulation, and hence the baseline encoding only uses the 11
codepoint to indicate PCN-marking. Extended encoding schemes need to

Eardley Informational [Page 24]

RFC 5559 PCN Architecture June 2009

explain their interactions with (or assumptions about) tunnelling. A
lengthy discussion of all the issues associated with layered
encapsulation of congestion notification (for ECN as well as PCN) is
in [Briscoe08-2]. [Briscoe09].

4.8. Fault handling Handling

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

If a PCN-boundary-node fails fails, then we would like the regular QoS
signalling protocol to be responsible for taking appropriate action.
As an example [Briscoe08-2] example, [Briscoe09] considers what happens if RSVP is the QoS
signalling protocol.

5. Operations and Management

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

Eardley (Editor) Expires October 9, 2009 [Page 26]

Internet-Draft PCN Architecture April 2009 discussed with performance.

5.1. Configuration Fault Operations and Management

Threshold-metering and -marking and excess-traffic-metering

Fault Operations and
-marking are standardised in [PCN08-2]. However, more diversity in
PCN-boundary-node behaviours is expected, in order to interface with
diverse industry architectures. It may be possible to have different
PCN-boundary-node behaviours for different ingress-egress-aggregates
within the same PCN-domain.

PCN metering behaviour Management is enabled on either about preventing faults, telling
the egress or management system (or manual operator) that the ingress
interfaces of PCN-nodes. A consistent choice must system has
recovered (or not) from a failure, and about maintaining information
to aid fault diagnosis.

Admission blocking and, particularly, flow termination mechanisms
should rarely be made across the
PCN-domain needed in practice. It would be unfortunate if they
didn't work after an option had been accidentally disabled.
Therefore, it will be necessary to ensure regularly test that the PCN mechanisms protect all links.

PCN configuration control variables fall into the following
categories:

o live
system options (enabling or disabling behaviours)

o parameters (setting levels, addresses etc)

One possibility works as intended (devising a meaningful test is that all configurable variables sit within left as an SNMP
management framework [RFC3411], being structured within a defined
management information base (MIB) on each node, and being remotely
readable and settable via a suitably secure management protocol
(SNMPv3).

Some configuration options and parameters have
exercise for the operator).

Section 4 describes how the PCN architecture has been designed to be set once
ensure admitted flows continue gracefully after recovering
automatically from link or node failures. The need to
'globally' control the whole PCN-domain. Where possible, these are
identified below. This may affect operational complexity record and
monitor re-routing events affecting signalling is unchanged by the
chances

Eardley Informational [Page 25]

RFC 5559 PCN Architecture June 2009

addition of interoperability problems between equipment from different
vendors.

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

5.1.1. System options

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

o Whether two PCN-markings (threshold-marked recorded and excess-traffic-
marked) are enabled or only one. Typically all nodes throughout a
PCN-domain will monitored just as they
would be configured without PCN.

PCN-marking does make it possible to record "near-misses". For
instance, at the same in this respect. However,
exceptions PCN-egress-node a "reporting threshold" could be made. For example, if most PCN-nodes used
both markings, but some legacy hardware was incapable of running
two algorithms, an operator might be willing set
to configure these

Eardley (Editor) Expires October 9, 2009 [Page 27]

Internet-Draft PCN Architecture April 2009

legacy nodes solely monitor how often -- and for excess-traffic-marking how long -- the system comes close to enable
triggering flow blocking without actually doing so. Similarly,
bursts of flow termination as a back-stop. It would marking could be sensible to place such
nodes where recorded even if they are
not sufficiently sustained to trigger flow termination. Such
statistics could be provisioned correlated with a greater leeway over
expected traffic levels.

o In the case where only one PCN-marking is enabled, all nodes must
be configured per-queue counts of marking
volume (Section 5.2) to generate PCN-marks from the same meter (ie either
the threshold meter upgrade resources in danger of causing
service degradation or the excess traffic meter).

PCN-boundary-nodes (ingress and egress) will to trigger manual tracing of intermittent
incipient errors that would otherwise have more system
options:

o Which gone unnoticed.

Finally, of admission and flow termination course, many faults are enabled. If any PCN-
interior-node is caused by failings in the
management process ("human error"): a wrongly configured to generate address in a marking, all PCN-
boundary-nodes must be able to interpret that marking (which
includes understanding,
node, a wrong address given in a PCN-domain that uses only one type of
PCN-marking, whether they are generated by PCN-interior-nodes'
threshold meters or the excess traffic meters). Therefore all
PCN-boundary-nodes must be signalling protocol, a wrongly
configured the same parameter in a queueing algorithm, a node set into a
different mode from other nodes, and so on. Generally, a clean
design with few configurable options ensures this respect.

o Where flow admission class of faults can
be traced more easily and termination decisions are made: at PCN-
ingress-nodes or at PCN-egress-nodes (or prevented more often. Sound management
practice at run-time also helps. For instance, a centralised node,
see Appendix). Theoretically, this configuration choice could management system
should be
negotiated for each pair of PCN-boundary-nodes, but we cannot
imagine why such complexity would used that constrains configuration changes within system
rules (eg, preventing an option setting inconsistent with other
nodes), configuration options should be required, except perhaps recorded in
future inter-domain scenarios.

o How PCN-markings are translated into admission control an offline
database, and flow
termination decisions (see Section 3.1 regular automatic consistency checks between live
systems and Section 3.2).

PCN-egress-nodes will have further system options:

o How the mapping database should be established between each packet performed. PCN adds nothing
specific to this class of problems.

5.2. Configuration Operations and its
aggregate, eg by MPLS label, by IP packet filter spec; Management

Threshold-metering and how -marking and excess-traffic-metering and
-marking are standardised in [Eardley09]. However, more diversity in
PCN-boundary-node behaviours is expected, in order to
take account of ECMP.

o If an equipment vendor provides a choice, there interface with
diverse industry architectures. It may be options to
select which smoothing algorithm possible to use have different
PCN-boundary-node behaviours for measurements.

5.1.2. Parameters

Like any Diffserv domain, every node different ingress-egress-aggregates
within a PCN-domain will need to
be configured with the DSCP(s) used to identify PCN-packets. On each
interior link same PCN-domain.

PCN-metering behaviour is enabled on either the main configuration parameters are egress or the PCN-
threshold-rate and PCN-excess-rate. ingress
interfaces of PCN-nodes. A larger PCN-threshold-rate
enables more PCN-traffic to consistent choice must be admitted on a link, hence improving
capacity utilisation. A PCN-excess-rate set further above made across the PCN-
threshold-rate allows greater increases in traffic (whether due
PCN-domain to ensure that the PCN mechanisms protect all links.

Eardley (Editor) Expires October 9, 2009 Informational [Page 28]

Internet-Draft 26]

RFC 5559 PCN Architecture April June 2009

natural fluctuations

PCN configuration control variables fall into the following
categories:

o system options (enabling or some unexpected event) before any flows disabling behaviours)

o parameters (setting levels, addresses, etc.)

One possibility is that all configurable variables sit within an SNMP
(Simple Network Management Protocol) management framework [RFC3411],
being structured within a defined management information base (MIB)
on each node, and being remotely readable and settable via a suitably
secure management protocol (such as SNMPv3).

Some configuration options and parameters have to be set once to
"globally" control the whole PCN-domain. Where possible, these are
terminated, ie minimises
identified below. This may affect operational complexity and the
chances of unnecessarily triggering the
termination mechanism. For instance, interoperability problems between equipment from different
vendors.

It may be possible for an operator may want to design
their network configure some PCN-interior-
nodes so that they don't run the PCN mechanisms, if it can cope with a failure of any single PCN-
node without terminating any flows.

Setting knows that
these rates on first deployment of PCN links will be very similar
to the traditional process for sizing an admission controlled
network, depending on: the operator's requirements for minimising
flow blocking (grade of service), the expected PCN traffic load on
each link never become (pre-)congested.

5.2.1. System Options

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

o Whether two PCN-markings (threshold-marked and its statistical characteristics (the traffic matrix),
contingency for re-routing the PCN traffic matrix in the event of
single excess-traffic-
marked) are enabled or multiple failures, and the expected load from other classes
relative to link capacities [Menth07]. But once a domain is in
operation, only one. Typically, all nodes throughout
a PCN design goal is to PCN-domain will be able to determine growth in
these configured rates much more simply, by monitoring PCN-marking
rates from actual rather than expected traffic (see Section 5.2 on
Performance & Provisioning).

Operators may also wish to configure a rate greater than the PCN-
excess-rate that is the absolute maximum rate that a link allows for
PCN-traffic. This may simply same in this respect.
However, exceptions could be the physical link rate, made. For example, if most PCN-nodes
used both markings but some
operators may wish legacy hardware was incapable of
running two algorithms, an operator might be willing to configure a logical limit
these legacy nodes solely for excess-traffic-marking to prevent starvation
of other traffic classes during any brief period after PCN-traffic
exceeds the PCN-excess-rate but before enable
flow termination brings it
back below this rate.

Threshold-metering requires as a threshold token bucket depth back-stop. It would be sensible to place
such nodes where they could be
configured, excess-traffic-metering needs a value for the MTU
(maximum size of provisioned with a PCN-packet on greater leeway
over expected traffic levels.

o In the link) and both require setting a
maximum size of their token buckets. It will be preferable for there
to case where only one PCN-marking is enabled, all nodes must
be rules to set defaults for these parameters, but then allow
operators configured to change them, for instance if average traffic
characteristics change over time.

The PCN-egress-node may allow configuration of generate PCN-marks from the following: same meter (ie,
either the threshold meter or the excess-traffic meter).

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

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

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

o an admission control algorithm that are enabled. If any PCN-
interior-node is based on the fraction of
marked packets will at least require configured to generate a marking threshold setting
above which it denies admission marking, all PCN-
boundary-nodes must be able to new flows; interpret that marking (which

Eardley (Editor) Expires October 9, 2009 Informational [Page 29]

Internet-Draft 27]

RFC 5559 PCN Architecture April June 2009

includes understanding, in a PCN-domain that uses only one type of
PCN-marking, whether they are generated by PCN-interior-nodes'
threshold meters or their excess-traffic meters). Therefore, all
PCN-boundary-nodes must be configured the same in this respect.

o Where flow admission and termination algorithms will probably require decisions are made: at PCN-
ingress-nodes or at PCN-egress-nodes (or at a parameter to
delay termination centralised node,
see Appendix). Theoretically, this configuration choice could be
negotiated for each pair of any flows until it is more certain that an
anomalous event is not transient; PCN-boundary-nodes, but we cannot
imagine why such complexity would be required, except perhaps in
future inter-domain scenarios.

o a parameter to How PCN-markings are translated into admission control and flow
termination decisions (see Sections 3.1 and 3.2).

PCN-egress-nodes will have further system options:

o How the trade-off mapping should be established between how quickly excess
flows are terminated, each packet and over-termination.

One particular approach, [Charny07-2] would require a global
parameter its
aggregate (eg, by MPLS label and by IP packet filter spec) and how
to take account of ECMP.

o If an equipment vendor provides a choice, there may be defined on all PCN-nodes, but only needs one PCN
marking rate options for
selecting which smoothing algorithm to use for measurements.

5.2.2. Parameters

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

Setting these rates on the operation first deployment of PCN.

5.2. Performance & Provisioning Operations and Management

Monitoring of performance factors measurable from *outside* the PCN
domain will be no different with PCN than with any other packet-based
flow admission control system, both at very
similar to the traditional process for sizing an admission-controlled
network, depending on: the operator's requirements for minimising
flow level (blocking
probability, etc) blocking (grade of service), the expected PCN-traffic load on
each link and its statistical characteristics (the traffic matrix),
contingency for re-routing the packet level (jitter [RFC3393], [Y.1541],
loss rate [RFC4656], mean opinion score [P.800], etc). The
difference is that PCN is intentionally designed to indicate
*internally* which exact resource(s) are PCN-traffic matrix in the cause event of performance
problems
single or multiple failures, and by how much.

Even better, the expected load from other classes
relative to link capacities [Menth09-1]. But, once a domain is in
operation, a PCN indicates which resources will probably cause
problems if they are not upgraded soon. This can design goal is to be achieved able to determine growth in

Eardley Informational [Page 28]

RFC 5559 PCN Architecture June 2009

these configured rates much more simply, by the
management system monitoring PCN-marking
rates from actual rather than expected traffic (see Section 5.4 on
Performance and Provisioning).

Operators may also wish to configure a rate greater than the total amount (in bytes) of PCN-
marking generated by each queue over a period. Given possible long
provisioning lead times, pre-congestion volume
excess-rate that is the best metric absolute maximum rate that a link allows for
PCN-traffic. This may simply be the physical link rate, but some
operators may wish to
reveal whether sufficient persistent demand has occurred configure a logical limit to warrant
an upgrade. Because, even before utilisation becomes problematic,
the statistical variability prevent starvation
of other traffic will cause occasional bursts
of pre-congestion. This 'early warning system' decouples the process
of adding customers from the provisioning process. This should cut classes during any brief period after PCN-traffic
exceeds the time to add a customer when compared against admission control
provided over native Diffserv [RFC2998], because PCN-excess-rate but before flow termination brings it saves having
back below this rate.

Threshold-metering requires a threshold token bucket depth to
verify the capacity planning process before adding each customer.

Alternatively, before triggering an upgrade, the long term pre-
congestion volume on each link can be used to balance traffic load
across the PCN-domain by adjusting
configured, excess-traffic-metering requires a value for the link weights MTU
(maximum size of a PCN-packet on the routing
system. When an upgrade to link), and both require setting
a link's configured PCN-rates maximum size of their token buckets. It is
required, it may also be necessary preferable to upgrade the physical capacity
available have
rules that set defaults for these parameters but to other classes. But usually there then allow
operators to change them -- for instance, if average traffic
characteristics change over time.

The PCN-egress-node may allow configuration of:

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

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

o An admission control algorithm that is based on the upgrade to go ahead as fraction of
marked packets will at least require a simple
configuration change. Alternatively, [Songhurst06] describes an

Eardley (Editor) Expires October 9, 2009 [Page 30]

Internet-Draft PCN Architecture April 2009

adaptive rather than preconfigured system, where the configured PCN-
threshold-rate is replaced with a high and low water mark and the marking algorithm automatically optimises how physical capacity threshold setting
above which it denies admission to new flows.

o Flow termination algorithms will probably require a parameter to
delay termination of any flows until it is
shared using more certain that an
anomalous event is not transient.

o A parameter to control the relative loads from PCN trade-off between how quickly excess
flows are terminated and other traffic classes.

All the above processes over-termination.

One particular approach [Charny07-2] would require just three extra counters associated
with each PCN queue: threshold-markings, excess-traffic-markings and
drop. Every time a PCN packet is marked or dropped its size in bytes
should global parameter
to be added defined on all PCN-nodes, but would only need one PCN-marking
rate to the appropriate counter. Then the management
system can read the counters at any time be configured on each link. The global parameter is a
scaling factor between admission and subtract termination (the rate of PCN-
traffic on a previous
reading link up to establish which flows are admitted vs. the incremental volume rate above
which flows are terminated). [Charny07-2] discusses in full the
impact of each type this particular approach on the operation of
(pre-)congestion. Readings should be taken frequently, so that
anomalous events (eg re-routes) can be distinguished from regular
fluctuating demand if required. PCN.

Eardley Informational [Page 29]

RFC 5559 PCN Architecture June 2009

5.3. Accounting Operations and Management

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

5.4. Fault Operations Performance and Management

Fault Provisioning Operations and Management is about preventing faults, telling

Monitoring of performance factors measurable from *outside* the management system (or manual operator) that the system has
recovered (or not) from a failure, and about maintaining information
to aid fault diagnosis.

Admission blocking and particularly flow termination mechanisms
should rarely be needed in practice. It would be unfortunate if they
didn't work after an option had been accidentally disabled.
Therefore it PCN-
domain will be necessary to regularly test that the live system
works as intended (devising a meaningful test is left as an exercise
for no different with PCN than with any other packet-
based, flow admission control system, both at the operator).

Section 4 describes how flow level
(blocking probability, etc.) and the packet level (jitter [RFC3393],
[Y.1541], loss rate [RFC4656], mean opinion score [P.800], etc.).
The difference is that PCN architecture has been is intentionally designed to
ensure admitted flows continue gracefully after recovering
automatically from link or node failures. The need to record and
monitor re-routing events affecting signalling is unchanged by indicate
*internally* which exact resource(s) are the
addition cause of performance
problems and by how much.

Even better, PCN to a Diffserv domain. Similarly, re-routing events
within the PCN-domain indicates which resources will be recorded and monitored just as probably cause
problems if they
would are not upgraded soon. This can be without PCN.

PCN-marking does make it possible to record 'near-misses'. For
instance, at achieved by the PCN-egress-node
management system monitoring the total amount (in bytes) of PCN-
marking generated by each queue over a 'reporting threshold' could be set
to monitor how often - and for how period. Given possible long -
provisioning lead times, pre-congestion volume is the system comes close best metric to

Eardley (Editor) Expires October 9, 2009 [Page 31]

Internet-Draft PCN Architecture April 2009

triggering flow blocking without actually doing so. Similarly,
bursts of flow termination marking could be recorded even if they are
not sufficiently sustained to trigger flow termination. Such
statistics could be correlated with per-queue counts of marking
volume (Section 5.2) to upgrade resources in danger of causing
service degradation, or to trigger manual tracing of intermittent
incipient errors that would otherwise have gone unnoticed.

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

5.5. Security Operations and Management

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

o Anomalous patterns of non-conforming incoming signals and packets
rejected at the PCN-ingress-nodes (eg packets already marked PCN-
capable, or traffic persistently starving token bucket policers).

o PCN-capable packets arriving at a PCN-egress-node with no
associated state for mapping them to a valid ingress-egress-
aggregate.

Eardley (Editor) Expires October 9, 2009 [Page 32]

Internet-Draft PCN Architecture April 2009

o A PCN-ingress-node receiving feedback signals about the pre-
congestion level on a non-existent aggregate, or that are
inconsistent with other signals (eg unexpected sequence numbers,
inconsistent addressing, conflicting reports of the pre-congestion
level, etc).

o Pre-congestion marking arriving at a PCN-egress-node with
(pre-)congestion markings focused on particular flows, rather than
randomly distributed throughout the aggregate.

6. Applicability of PCN

6.1. Benefits

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

o Per flow state is only required at the PCN-ingress-nodes
("stateless core"). This is required for policing purposes (to
prevent non-admitted PCN traffic from entering the PCN-domain) and
so on. It is not generally required that other network entities
are aware of individual flows (although they may be in particular
deployment scenarios).

o Admission control is resilient: with PCN QoS is decoupled from the
routing system. Hence in general admitted flows can survive
capacity, routing or topology changes without additional
signalling. The PCN-admissible-rate on each link can be chosen
small enough that admitted traffic can still be carried after a
rerouting in most failure cases [Menth07]. This is an important
feature as QoS violations in core networks due to link failures
are more likely than QoS violations due to increased traffic
volume [Iyer03].

o The PCN-metering behaviours only operate on the overall PCN-
traffic on the link, not per flow.

o The information of these measurements is signalled to the PCN-
egress-nodes by the PCN-marks in the packet headers, ie [Style]
"in-band". No additional signalling protocol is required for
transporting the PCN-marks. Therefore no secure binding is
required between data packets and separate congestion messages.

o The PCN-egress-nodes make separate measurements, operating on the
aggregate PCN-traffic from each PCN-ingress-node, ie not per flow.
Similarly, signalling by the PCN-egress-node of PCN-feedback-
information (which is used for flow admission and termination

Eardley (Editor) Expires October 9, 2009 [Page 33]

Internet-Draft PCN Architecture April 2009

decisions) is at the granularity of the ingress-egress-aggregate.
An alternative approach is that the PCN-egress-nodes monitor the
PCN-traffic and signal PCN-feedback-information (which is used for
flow admission and termination decisions) at the granularity of
one (or a few) PCN-marks.

o The admitted PCN-load is controlled dynamically. Therefore it
adapts as the traffic matrix changes, and also if the network
topology changes (eg after a link failure). Hence an operator can
be less conservative when deploying network capacity, and less
accurate in their prediction of the PCN-traffic matrix.

o The termination mechanism complements admission control. It
allows the network to recover from sudden unexpected surges of
PCN-traffic on some links, thus restoring QoS to the remaining
flows. Such scenarios are expected to be rare but not impossible.
They can be caused by large network failures that redirect lots of
admitted PCN-traffic to other links, or by malfunction of the
measurement-based admission control in the presence of admitted
flows that send for a while with an atypically low rate and then
increase their rates in a correlated way.

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]). Fully protecting traffic against a single SRLG
failure requires low utilisation (~10%) of the link bandwidth on
some links before failure [Charny08].

o The PCN-supportable-rate may be set below the maximum rate that
PCN-traffic can be transmitted on a link, in order to trigger
termination of some PCN-flows before loss (or excessive delay) of
PCN-packets occurs, or to keep the maximum PCN-load on a link
below a level configured by the operator.

o Provisioning of the network is decoupled from the process of
adding new customers. By contrast, with the Diffserv architecture
[RFC2475] operators rely on subscription-time Service Level
Agreements, which statically define the parameters of the traffic
that will be accepted from a customer, and so the operator has to
verify provision is sufficient each time a new customer is added
to check that the Service Level Agreement can be fulfilled. A
PCN-domain doesn't need such traffic conditioning.

Eardley (Editor) Expires October 9, 2009 [Page 34]

Internet-Draft PCN Architecture April 2009

6.2. Deployment scenarios

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

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

On the other hand, a PCN-domain may have two encoding states (as in
[PCN08-1]) (or pedantically, an operator may choose to use up two
encoding states for PCN): not PCN-marked, PCN-marked. Then there are
three possibilities, as discussed in the following paragraphs (see
also Section 3.3).

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

Second, an operator could just rely for admission control on
statically provisioned capacity per PCN-ingress-node (regardless of
the PCN-egress-node of a flow), as is typical in the hose model of
the Diffserv architecture [RFC2475]. Such traffic conditioning
agreements can lead to focused overload: many flows happen to focus
on a particular link and then all flows through the congested link
fail catastrophically. PCN's flow termination mechanism could then
be used to counteract such a problem.

Third, both admission control and flow termination can be triggered
from the single type of PCN-marking; the main downside is that
admission control is less accurate [Charny07-2]. This possibility is
illustrated in Figure 3.

Eardley (Editor) Expires October 9, 2009 [Page 35]

Internet-Draft PCN Architecture April 2009

Within the PCN-domain there is some flexibility about how the
decision making functionality is distributed. These possibilities
are outlined in Section 4.4 and also discussed elsewhere, such as in
[Menth08-3].

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

PCN admission control has to fit with the overall approach to
admission control. For instance [Briscoe06] describes the case where
RSVP signalling runs end-to-end. The PCN-domain is a single RSVP
hop, ie only the PCN-boundary-nodes process RSVP messages, with RSVP
messages processed on each hop outside the PCN-domain, as in IntServ
over Diffserv [RFC2998]. 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
reveal whether sufficient persistent demand has occurred to warrant
an upgrade because, even before utilisation becomes problematic, the proxy (eg
SIP signalling with a home hub). A similar example would use NSIS
signalling instead
statistical variability of RSVP. (NSIS: Next Steps in Signalling,
[RFC3726].)

It is possible that a user wants its inelastic traffic to use the PCN
mechanisms but also react to ECN marking outside the PCN-domain
[Sarker08]. Two possible ways to do this are to tunnel all PCN-
packets across will cause occasional bursts of
pre-congestion. This "early warning system" decouples the PCN-domain, so that process of
adding customers from the ECN marks are carried
transparently across provisioning process. This should cut the PCN-domain, or
time to use an encoding like
[Moncaster08]. Tunnelling is discussed further in Section 4.7.

Some further possible deployment models are outlined in the Appendix.

6.3. Assumptions and constraints on scope

The scope is restricted by the following assumptions:

1. these components are deployed in add a single customer when compared against admission control that
is provided over native Diffserv domain, within
which all PCN-nodes are PCN-enabled and are trusted for truthful
PCN-marking and transport

2. all flows handled by these mechanisms are inelastic and
constrained [RFC2998] because it saves having to a known peak rate through policing or shaping

Eardley (Editor) Expires October 9, 2009 [Page 36]

Internet-Draft PCN Architecture April 2009

3.
verify the number of PCN-flows across any potential bottleneck link is
sufficiently large that stateless, statistical mechanisms can be
effective. To put it another way, capacity-planning process before adding each customer.

Alternatively, before triggering an upgrade, the aggregate bit rate of PCN-
traffic across any potential bottleneck long-term pre-
congestion volume on each link needs to can be
sufficiently large relative used to balance traffic load
across the maximum additional bit rate
added PCN-domain by one flow. This is the basic assumption of measurement-
based admission control.

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

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

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

o The PCN-domain has routing
system. When an upgrade to be encircled by a ring of PCN-boundary-
nodes, otherwise traffic could enter a PCN-BA without being
subject link's configured PCN-rates is
required, it may also be necessary to admission control, which would potentially degrade upgrade the
QoS of existing PCN-flows.

o Similarly, a PCN-boundary-node has physical capacity
available to trust that all the PCN-nodes
mark PCN-traffic consistently. A node not performing PCN-marking
wouldn't other classes. However, there will usually be able to alert when it suffered pre-congestion, which
potentially would lead
sufficient physical capacity for the upgrade to too many PCN-flows being admitted (or
too few being terminated). Worse, a rogue node could perform
various attacks, go ahead as discussed in a simple
configuration change. Alternatively, [Songhurst06] describes an
adaptive rather than preconfigured system, where the Security Considerations
section.

One way of assuring configured PCN-
threshold-rate is replaced with a high and low water mark and the
marking algorithm automatically optimises how physical capacity is
shared, using the relative loads from PCN and other traffic classes.

Eardley Informational [Page 30]

RFC 5559 PCN Architecture June 2009

All the above two points is that the entire PCN-
domain is run by processes require just three extra counters associated
with each PCN queue: threshold-markings, excess-traffic-markings, and
drops. Every time a single operator. Another possibility PCN-packet is that
there are several operators that trust each other marked or dropped, its size in their handling
of PCN-traffic.

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

6.3.2. Assumption 2: Real-time applications

It is assumed that appropriate counter. Then the
management system can read the counters at any variation of source bit rate is independent of time and subtract a
previous reading to establish the level incremental volume of pre-congestion. We assume each type of
(pre-)congestion. Readings should be taken frequently so that PCN-packets come
anomalous events (eg, re-routes) can be distinguished from
real time applications generating inelastic traffic, ie sending
packets regular
fluctuating demand, if required.

5.5. Security Operations and Management

Security Operations and Management is about using secure operational
practices as well as being able to track security breaches or near-
misses at the rate the codec produces them, regardless of the

Eardley (Editor) Expires October 9, 2009 [Page 37]

Internet-Draft run-time. PCN Architecture April 2009

availability adds few specifics to the general good
practice required in this field [RFC4778]. The correct functions of capacity [RFC4594]. For example, voice and video
requiring low delay, jitter and packet loss,
the Controlled Load
Service, [RFC2211], system should be monitored (Section 5.4) in multiple independent
ways and the Telephony service class, [RFC4594]. This
assumption is correlated to help focus detect possible security breaches. Persistent
(pre-)congestion marking should raise an alarm (both on the effort where it looks like PCN would
be most useful, ie node
doing the sorts of applications where per flow QoS is a
known requirement. In other words we focus marking and on PCN providing a
benefit to inelastic traffic (PCN may the PCN-egress-node metering it).
Similarly, persistently poor external QoS metrics (such as jitter or
mean opinion score) should raise an alarm. The following are
examples of symptoms that may not provide a benefit to
other types be the result of traffic).

As innocent faults,
rather than attacks; however, until diagnosed, they should be logged
and should trigger a consequence, it is assumed that PCN-metering security alarm:

o Anomalous patterns of non-conforming incoming signals and PCN-marking is
being applied to traffic scheduled with packets
rejected at the expedited forwarding per-
hop behaviour, [RFC3246], PCN-ingress-nodes (eg, packets already marked PCN-
capable or traffic persistently starving token bucket policers).

o PCN-capable packets arriving at a per-hop behaviour PCN-egress-node with similar
characteristics.

6.3.3. Assumption 3: Many flows and additional load

It is assumed no
associated state for mapping them to a valid ingress-egress-
aggregate.

o A PCN-ingress-node receiving feedback signals that there are many PCN-flows about the
pre-congestion level on any bottleneck link in a non-existent aggregate or that are
inconsistent with other signals (eg, unexpected sequence numbers,
inconsistent addressing, conflicting reports of the PCN-domain (or, to put it another way, pre-congestion
level, etc.).

o Pre-congestion marking arriving at a PCN-egress-node with
(pre-)congestion markings focused on particular flows, rather than
randomly distributed throughout the aggregate bit rate aggregate.

Eardley Informational [Page 31]

RFC 5559 PCN Architecture June 2009

6. Applicability of PCN

6.1. Benefits

The key benefits of
PCN-traffic across any potential bottleneck link is sufficiently
large relative to the maximum additional bit rate added by one PCN-
flow). Measurement-based admission control assumes PCN mechanisms are that the present they are simple,
scalable, and robust, because:

o Per-flow state is a reasonable prediction of only required at the future: PCN-ingress-nodes
("stateless core"). This is required for policing purposes (to
prevent non-admitted PCN-traffic from entering the PCN-domain) and
so on. It is not generally required that other network conditions entities
are
measured at the time aware of a new flow request, however the actual
network performance must individual flows (although they may be acceptable during the call some time
later. One issue in particular
deployment scenarios).

o Admission control is that if there are only a few variable rate
flows, then resilient: with PCN, QoS is decoupled from
the aggregate routing system. Hence, in general, admitted flows can survive
capacity, routing, or topology changes without additional
signalling. The PCN-admissible-rate on each link can be chosen to
be small enough that admitted traffic level may vary can still be carried after a lot, perhaps
enough to cause some packets
re-routing in most failure cases [Menth09-1]. This is an
important feature, as QoS violations in core networks due to get dropped. If there link
failures are many flows
then the aggregate more likely than QoS violations due to increased
traffic level should be statistically smoothed.
How many flows is enough depends volume [Iyer03].

o The PCN-metering behaviours only operate on a number of factors such as the
variation in each flow's rate, overall PCN-
traffic on the total rate link, not per flow.

o The information of PCN-traffic, and these measurements is signalled to the
size of PCN-
egress-nodes by the "safety margin" between PCN-marks in the traffic level at which we
start admission-marking and at which packets are dropped or
significantly delayed. packet headers, ie, "in-
band". No explicit assumptions are made about how many PCN-flows are in each
ingress-egress-aggregate. Performance evaluation work may clarify
whether it additional signalling protocol is necessary to required for
transporting the PCN-marks. Therefore, no secure binding is
required between data packets and separate congestion messages.

o The PCN-egress-nodes make any additional assumption separate measurements, operating on
aggregation at the ingress-egress-aggregate level.

6.3.4. Assumption 4: Emergency use out of scope

PCN-flows may have different precedence, but
aggregate PCN-traffic from each PCN-ingress-node, ie, not per
flow. Similarly, signalling by the applicability PCN-egress-node of the
PCN mechanisms PCN-
feedback-information (which is used for emergency use (911, GETS, WPS, MLPP, etc) flow admission and
termination decisions) is out
of scope at the granularity of this document.

Eardley (Editor) Expires October 9, 2009 [Page 38]

Internet-Draft PCN Architecture April 2009

6.4. Challenges

Prior work on PCN the ingress-
egress-aggregate. An alternative approach is that the PCN-egress-
nodes monitor the PCN-traffic and similar mechanisms has thrown up a number of
considerations about PCN's design goals (things PCN should be good
at) signal PCN-feedback-information
(which is used for flow admission and some issues that have been hard to solve in a fully
satisfactory manner. Taken as termination decisions) at
the granularity of one (or a whole few) PCN-marks.

o The admitted PCN-load is controlled dynamically. Therefore, it represents
adapts as the traffic matrix changes. It also adapts if the
network topology changes (eg, after a list of trade-
offs (it is unlikely that they link failure). Hence, an
operator can all be 100% achieved) less conservative when deploying network capacity
and perhaps
as evaluation criteria to help an operator (or less accurate in their prediction of the IETF) decide
between options. PCN-traffic matrix.

Eardley Informational [Page 32]

RFC 5559 PCN Architecture June 2009

o The following are open issues. They are mainly taken termination mechanism complements admission control. It
allows the network to recover from
[Briscoe06], which also describes some possible solutions. Note that sudden unexpected surges of
PCN-traffic on some may be considered unimportant in general or in specific
deployment links, thus restoring QoS to the remaining
flows. Such scenarios are expected to be rare but not impossible.
They can be caused by large network failures that redirect lots of
admitted PCN-traffic to other links or by some operators.

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

o ECMP (Equal Cost Multi-Path) Routing: The level
measurement-based admission control in the presence of pre-congestion
is measured on admitted
flows that send for a specific ingress-egress-aggregate. However, if
the PCN-domain runs ECMP, while with an atypically low rate and then traffic on this ingress-egress-
aggregate may follow several different paths - some of the paths
could be pre-congested whilst others are not. There are three
potential problems:

1. over-admission:
increase their rates in a new flow correlated way.

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 admitted (because the pre-
congestion level measured by especially the PCN-egress-node is
sufficiently diluted by unmarked packets from non-congested
paths
case with SRLGs (shared risk link groups), which are links that
share a new flow is admitted), but its packets travel
through resource, such as a pre-congested PCN-node.

2. under-admission: fibre, whose failure affects all links
in that group [RFC4216]). Fully protecting traffic against a new flow is blocked (because
single SRLG failure requires low utilisation (~10%) of the pre-
congestion level measured by link
bandwidth on some links before failure [Charny08].

o The PCN-supportable-rate may be set below the PCN-egress-node is
sufficiently increased by PCN-marked packets from pre-
congested paths maximum rate that
PCN-traffic can be transmitted on a new flow is blocked), but its packets
travel along an uncongested path.

3. ineffective termination: a flow is terminated, but its path
doesn't travel through link in order to trigger the (pre-)congested router(s). Since
flow
termination is a 'last resort', which protects the
network should over-admission occur, this problem is probably
more important of some PCN-flows before loss (or excessive delay) of
PCN-packets occurs, or to solve than keep the other two.

o ECMP and signalling: It is possible that, in maximum PCN-load on a PCN-domain running
ECMP, the signalling packets (eg RSVP, NSIS) follow link
below a different
path than level configured by the data packets, which could matter if operator.

o Provisioning of the signalling
packets are used as probes. Whether this network is an issue depends decoupled from the process of
adding new customers. By contrast, with the Diffserv architecture
[RFC2475], operators rely on subscription-time Service Level
Agreements, which fields statically define the parameters of the ECMP algorithm uses; if traffic
that will be accepted from a customer. This way, the ECMP algorithm operator has
to verify that provision is
restricted sufficient each time a new customer is
added to check that the source and destination IP addresses, then it

Eardley (Editor) Expires October 9, 2009 [Page 39]

Internet-Draft PCN Architecture April 2009

will not Service Level Agreement can be an issue. ECMP and signalling interactions are a
specific instance fulfilled.
A PCN-domain doesn't need such traffic conditioning.

6.2. Deployment Scenarios

Operators of a general issue for non-traditional routing
combined with resource management along a path [Hancock02].

o Tunnelling: There are scenarios where tunnelling makes it
difficult networks will want to determine use the path PCN mechanisms in various
arrangements depending, for instance, on how they are performing
admission control outside the PCN-domain. The problem,
its impact, PCN-domain (users after all are
concerned about QoS end-to-end), what their particular goals and the potential solutions
assumptions are, how many PCN encoding states are similar available, and so
on.

A PCN-domain may have three encoding states (or pedantically, an
operator may choose to those use up three encoding states for
ECMP.

o Scenarios with only one tunnel endpoint PCN): not
PCN-marked, threshold-marked, and excess-traffic-marked. This way,
both PCN admission control and flow termination can be supported. As

Eardley Informational [Page 33]

RFC 5559 PCN Architecture June 2009

illustrated in Figure 1, admission control accepts new flows until
the PCN domain may make
it harder for PCN-traffic rate on the PCN-egress-node to gather from bottleneck link rises above the signalling
messages (eg RSVP, NSIS) PCN-
threshold-rate, whilst, if necessary, the identity of flow termination mechanism
terminates flows down to the PCN-excess-rate on the PCN-ingress-node.

o Bi-Directional Sessions: Many applications bottleneck link.

On the other hand, a PCN-domain may have bi-directional
sessions - hence there are two microflows that should be admitted encoding states (as in
[Moncaster09-1]) (or terminated) as a pair - pedantically, an operator may choose to use up
two encoding states for instance a bi-directional voice
call only makes sense if microflows in both directions PCN): not PCN-marked and PCN-marked. This
way, there are
admitted. However, three possibilities, as discussed in the PCN mechanisms concern following
paragraphs (see also Section 3.3).

First, an operator could just use PCN's admission and
termination of a single flow, and coordination of control, solving
heavy congestion (caused by re-routing) by "just waiting" -- as
sessions end, PCN-traffic naturally reduces; meanwhile, the decision for
both admission
control mechanism will prevent admission of new flows is a matter for that use the signalling protocol and out of
scope
affected links. So, the PCN-domain will naturally return to normal
operation, but with reduced capacity. The drawback of PCN. One possible example would use SIP pre-conditions.
However, there are others.

o Global Coordination: PCN makes its admission decision based on
PCN-markings on a particular ingress-egress-aggregate. Decisions
about flows through a different ingress-egress-aggregate are made
independently. However, one can imagine network topologies and
traffic matrices where, from a global perspective, it this approach
would be
better that, until sufficient sessions have ended to make a coordinated decision across relieve the
congestion, all PCN-flows as well as lower-priority services will be
adversely affected.

Second, an operator could just rely on statically provisioned
capacity per PCN-ingress-node (regardless of the ingress-
egress-aggregates PCN-egress-node of a
flow) for admission control, as is typical in the whole PCN-domain. For example, hose model of the
Diffserv architecture [Kumar01]. Such traffic-conditioning
agreements can lead to block
(or even terminate) focused overload: many flows happen to focus
on one ingress-egress-aggregate so that
more important a particular link and then all flows through a different ingress-egress-aggregate the congested link
fail catastrophically. PCN's flow termination mechanism could then
be admitted. The problem may well used to counteract such a problem.

Third, both admission control and flow termination can be relatively
insignificant.

o Aggregate Traffic Characteristics: Even when triggered
from the number single type of flows
is stable, the traffic level through PCN-marking; the PCN-domain will vary
because main downside here is that
admission control is less accurate [Charny07-2]. This possibility is
illustrated in Figure 3.

Within the sources vary their traffic rates. PCN works best when PCN-domain, there is not too much variability in some flexibility about how the total traffic level at a
PCN-node's interface (ie
decision-making functionality is distributed. These possibilities
are outlined in the aggregate traffic from all
sources). Too much variation means that a node may (at one
moment) not be doing any PCN-marking Section 4.4 and then (at another moment)
drop packets because it is overloaded. This makes it hard are also discussed elsewhere, such as
in [Menth09-2].

The flow admission and termination decisions need to tune be enforced
through per-flow policing by the admission control scheme PCN-ingress-nodes. If there are
several PCN-domains on the end-to-end path, then each needs to stop admitting new flows police
at its PCN-ingress-nodes. One exception is if the
right time. Therefore operator runs both
the problem is more likely with fewer,
burstier flows. access network (not a PCN-domain) and the core network (a PCN-
domain); per-flow policing could be devolved to the access network

Eardley (Editor) Expires October 9, 2009 Informational [Page 40]

Internet-Draft 34]

RFC 5559 PCN Architecture April June 2009

o Flash crowds

and Speed not be done at the PCN-ingress-node. Note that, to aid
readability, the rest of Reaction: PCN is a measurement-based
mechanism and so there this document assumes that policing is an inherent delay between packet marking done
by PCN-interior-nodes and any the PCN-ingress-nodes.

PCN admission control reaction at PCN-
boundary-nodes. has to fit with the overall approach to
admission control. For example, potentially if instance, [Briscoe06] describes the case
where RSVP signalling runs end-to-end. The PCN-domain is a big burst of
admission requests occurs single
RSVP hop, ie, only the PCN-boundary-nodes process RSVP messages, with
RSVP messages processed on each hop outside the PCN-domain, as in a very short space of time (eg
prompted by a televote), they could all get admitted before enough
PCN-marks are seen to block new flows. In other words, any
additional load offered within
IntServ over Diffserv [RFC2998]. It would also be possible for the reaction time of
RSVP signalling to be originated and/or terminated by proxies, with
application-layer signalling between the mechanism
must not move end user and the PCN-domain directly from proxy (eg,
SIP signalling with a no congestion state home hub). A similar example would use NSIS
(Next Steps in Signalling) [RFC3726] instead of RSVP.

It is possible that a user wants its inelastic traffic to overload. This 'vulnerability period' may have an impact at use the signalling level, for instance QoS requests should be rate
limited PCN
mechanisms but also react to bound ECN markings outside the number of requests able PCN-domain
[Sarker08]. Two possible ways to arrive within do this are to tunnel all PCN-
packets across the
vulnerability period.

o Silent at start: after a successful admission request PCN-domain, so that the source
may wait some time before sending data (eg waiting for ECN marks are carried
transparently across the called
party PCN-domain, or to answer). Then the risk use an encoding like
[Moncaster09-2]. Tunnelling is that, discussed further in Section 4.7.

Some further possible deployment models are outlined in some circumstances,
PCN's measurements underestimate what the pre-congestion level
will be when the source does start sending data.

7. IANA Considerations

This memo includes no request to IANA.

8. Security considerations

Security considerations essentially come from Appendix.

6.3. Assumptions and Constraints on Scope

The scope of this document is restricted by the Trust Assumption
(Section 6.3.1), ie that following
assumptions:

1. These components are deployed in a single Diffserv domain, within
which all PCN-nodes are PCN-enabled and are trusted for truthful PCN-metering and PCN-marking. PCN splits
functionality between PCN-interior-nodes and PCN-boundary-nodes,
PCN-marking and
the security considerations are somewhat different for each, mainly
because PCN-boundary-nodes transport.

2. All flows handled by these mechanisms are flow-aware inelastic and PCN-interior-nodes are
not.

o Because the PCN-boundary-nodes are flow-aware, they are trusted
constrained to
use that awareness correctly. a known peak rate through policing or shaping.

3. The degree of trust required
depends on the kinds number of decisions they have to make and PCN-flows across any potential bottleneck link is
sufficiently large that stateless, statistical mechanisms can be
effective. To put it another way, the kinds aggregate bit rate of information they need to make them. There is nothing specific
to PCN.

o The PCN-ingress-nodes police packets PCN-
traffic across any potential bottleneck link needs to ensure a PCN-flow sticks
within its agreed limit, and be
sufficiently large, relative to ensure that only PCN-flows that
have been admitted contribute PCN-traffic into the PCN-domain.
The policer must drop (or perhaps downgrade to a different DSCP)
any PCN-packets received that are outside this remit. maximum additional bit rate
added by one flow. This is
similar to the existing IntServ behaviour. Between them the PCN- basic assumption of measurement-
based admission control.

Eardley (Editor) Expires October 9, 2009 Informational [Page 41]

Internet-Draft 35]

RFC 5559 PCN Architecture April June 2009

boundary-nodes must encircle

4. PCN-flows may have different precedence, but the PCN-domain, otherwise PCN-packets
could enter applicability of
the PCN mechanisms for emergency use (911, GETS (Government
Telecommunications Service), WPS (Wireless Priority Service),
MLPP (Multilevel Precedence and Premption), etc.) is out of
scope.

6.3.1. Assumption 1: Trust and Support of PCN - Controlled Environment

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

o The PCN-domain has to be encircled by a ring of PCN-boundary-
nodes; otherwise, traffic could enter a PCN-BA without being
subject to admission control, which would potentially destroy degrade the
QoS of existing
flows. PCN-flows.

o PCN-interior-nodes are Similarly, a PCN-boundary-node has to trust that all the PCN-nodes
mark PCN-traffic consistently. A node not flow-aware. This prevents some
security attacks where performing PCN-marking
wouldn't be able to send an attacker targets specific flows alert when it suffered pre-congestion,
which potentially would lead to too many PCN-flows being admitted
(or too few being terminated). Worse, a rogue node could perform
various attacks, as discussed in Section 7.

One way of assuring the
data plane - for instance for DoS or eavesdropping.

o The PCN-boundary-nodes rely on correct PCN-marking by above two points are in effect is to have the PCN-
interior-nodes. For instance
entire PCN-domain run by a rogue PCN-interior-node could PCN-
mark all packets so that no flows were admitted. single operator. Another
possibility way is to have
several operators that it doesn't PCN-mark any packets, even when trust each other in their handling of PCN-
traffic.

Note: All PCN-nodes need to be trustworthy. However, if it is pre-congested. More subtly, the rogue PCN-interior-node could
perform these attacks selectively on particular flows, or known
that an interface cannot become pre-congested, then it could
PCN-mark the correct fraction overall, but carefully choose which
flows is not
strictly necessary for it marked.

o The PCN-boundary-nodes should be able to deal with DoS attacks and
state exhaustion attacks based on fast changes in per flow
signalling.

o The signalling between the PCN-boundary-nodes be capable of PCN-marking, but this must
be protected
from attacks. For example known even in unusual circumstances, eg, after the recipient needs to validate failure of some
links.

6.3.2. Assumption 2: Real-Time Applications

It is assumed that
the message any variation of source bit rate is indeed from independent of
the node level of pre-congestion. We assume that claims to have sent it.
Possible measures PCN-packets come from
real-time applications generating inelastic traffic, ie, sending
packets at the rate the codec produces them, regardless of the
availability of capacity [RFC4594]. Examples of such real-time
applications include digest authentication voice and protection
against replay video requiring low delay, jitter, and man-in-the-middle attacks. For
packet loss, the specific
protocol RSVP, hop-by-hop authentication is in [RFC2747], and
[Behringer07] may also be useful.

Operational security advice is given in Section 5.5.

9. Conclusions

The document describes a general architecture for flow admission and
termination based on pre-congestion information in order to protect Controlled Load Service [RFC2211], and the quality of Telephony
service of established inelastic flows within a single
Diffserv domain. The main topic class [RFC4594]. This assumption is to help focus the functional architecture. It
also mentions other topics effort
where it looks like PCN would be most useful, ie, the assumptions and open issues.

10. Acknowledgements

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

Eardley (Editor) Expires October 9, 2009 Informational [Page 42]

Internet-Draft 36]

RFC 5559 PCN Architecture April June 2009

Thanks to those who have made comments

applications where per-flow QoS is a known requirement. In other
words, we focus on this document: Lachlan
Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake, Ron
Bonica, Scott Bradner, Bob Briscoe, Ross Callon, Jason Canon, Ken
Carlberg, Anna Charny, Joachim Charzinski, Andras Csaszar, Francis
Dupont, Lars Eggert, Pasi Eronen, Adrian Farrel, Ruediger Geib, Wei
Gengyu, Robert Hancock, Fortune Huang, Christian Hublet, Cullen
Jennings, Ingemar Johansson, Georgios Karagiannis, Hein Mekkes,
Michael Menth, Toby Moncaster, Dimitri Papadimitriou, Dan Romascanu,
Daisuke Satoh, Ben Strulo, Tom Taylor, Hannes Tschofenig, Tina Tsou,
David Ward, Lars Westberg, Magnus Westerlund, Delei Yu. Thanks PCN providing a benefit to
Bob Briscoe who extensively revised the Operations inelastic traffic (PCN
may or may not provide a benefit to other types of traffic).

As a consequence, it is assumed that PCN-metering and Management
section.

This document PCN-marking is
being applied to traffic scheduled with an expedited forwarding per-
hop behaviour [RFC3246] or with a per-hop behaviour with similar
characteristics.

6.3.3. Assumption 3: Many Flows and Additional Load

It is the result of discussions assumed that there are many PCN-flows on any bottleneck link in
the PCN WG and
forerunner activity in PCN-domain (or, to put it another way, the TSVWG. A number aggregate bit rate of previous drafts were
presented
PCN-traffic across any potential bottleneck link is sufficiently
large, relative to TSVWG; their authors were: B, Briscoe, P. Eardley, D.
Songhurst, F. Le Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley,
G. Karagiannis, A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G.
Liu, A. Bhargava.

11. Comments Solicited (to be removed the maximum additional bit rate added by RFC Editor)

Comments and questions one PCN-
flow). Measurement-based admission control assumes that the present
is a reasonable prediction of the future: the network conditions are encouraged and very welcome. They can be
addressed to
measured at the IETF PCN working group mailing list <pcn@ietf.org>.

12. Changes (to time of a new flow request, but the actual network
performance must be removed by RFC Editor)

12.1. Changes from -10 to -11

Changes to deal with IESG comments from routing area review:

o Small clarifications to Introduction

o acceptable during the term "marking" now only used to refer call some time later. One
issue is that if there are only to setting the
codepoint (not as a shorthand for 'metering and setting the
codepoint')

o Added Figure 4 (Schematic of PCN-interior-node functionality)
(from [PCN08-2]

o Appendix A brought back into few variable rate flows, then the main body.

o Other minor clarifications

Eardley (Editor) Expires October 9, 2009 [Page 43]

Internet-Draft PCN Architecture April 2009

12.2. Changes from -09 to -10

Changes
aggregate traffic level may vary a lot, perhaps enough to deal with IESG comments:

o New introduction cause some
packets to provide gentler introduction for get dropped. If there are many flows, then the PCN
novice: quick summary of PCN's applicability; quick example aggregate
traffic level should be statistically smoothed. How many flows is
enough depends on a number of how
it all hangs together factors, such as the variation in one end-to-end qos scenario; quick
summary each
flow's rate, the total rate of PCN "documentation"

o OAM changed to Operations PCN-traffic, and Management

o Processed some the size of the minor suggestions in
"safety margin" between the Gen-ART Review by
Francis Dupont

o Two wording tweaks traffic level at which we start
admission-marking and at which packets are dropped or significantly
delayed.

No explicit assumptions are made about how many PCN-flows are in Sections 3.2 & 3.4 (as agreed on mailing
list)

o Updated boilerplate. this draft each
ingress-egress-aggregate. Performance-evaluation work may include material pre- Nov 10
2008 blah.

12.3. Changes from -08 to -09

Small changes to deal with WG Chair comments:

o tweak language in various places to make clarify
whether it more RFC-like and less
that of a scholarly work, for instance from "we propose" to "this
document describes"

o tweak language in various places is necessary to make it a stand alone
architecture document rather than a discussion any additional assumptions on
aggregation at the ingress-egress-aggregate level.

6.3.4. Assumption 4: Emergency Use Out of Scope

PCN-flows may have different precedence, but the PCN WG. Now
only mentions WG at start applicability of Annex.

o References: IDs are no longer referenced to by the draft name

o References: removed some
PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out
of less important references to IDs

12.4. Changes from -07 to -08

Small changes from second WG last call:

o Section 2: added definition scope for PCN-admissible-rate this document.

6.4. Challenges

Prior work on PCN and PCN-
supportable-rate. Small changes to use these terms as follows:
Section 3, bullets 2 & 9; S6.1 para 1; S6.2 para1; S6.3 bullet 3;
added similar mechanisms has led to Figs 1 & 2.

o added the phrase "(others might a number of
considerations about PCN's design goals (things PCN should be possible") before the good
at) and some issues that have been hard to solve in a fully
satisfactory manner. Taken as a whole, PCN represents a list of
approaches in Section 6.3, 7.4 & 7.5.

Eardley (Editor) Expires October 9, 2009 Informational [Page 44]

Internet-Draft 37]

RFC 5559 PCN Architecture April June 2009

o added references to RFC2753 (A framework for policy-based
admission control) in S7.4 & S7.5.

o throughout, updated references now

trade-offs (it is unlikely that marking behaviour &
baseline encoding are WG drafts.

o they can all be 100% achieved) and
perhaps a few typos corrected

12.5. Changes from -06 to -07

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

12.6. Changes from -05 list of evaluation criteria to -06

Minor clarifications throughout, help an operator (or the least insignificant
IETF) decide between options.

The following are as
follows:

o Section 1: added to the list of encoding states open issues. They are mainly taken from
[Briscoe06], which also describes some possible solutions. Note that
some may be considered unimportant in an 'extended'
scheme: "or perhaps further encoding states as suggested general or in
draft-westberg-pcn-load-control"

o Section 2: added definition specific
deployment scenarios, or by some operators.

Note: Potential solutions are out of scope for PCN-colouring (to clarify that the
term is used consistently differently from 'PCN-marking') this document.

o Section 6.1 and 6.2: added "(others might be possible)" before ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion
is measured on a specific ingress-egress-aggregate. However, if
the
list PCN-domain runs ECMP, then traffic on this ingress-egress-
aggregate may follow several different paths -- some of high the paths
could be pre-congested whilst others are not. There are three
potential problems:

1. over-admission: a new flow is admitted (because the pre-
congestion level approaches for making measured by the PCN-egress-node is
sufficiently diluted by unmarked packets from non-congested
paths that a new flow admission
(termination) decisions.

o Section 6.2: corrected is admitted), but its packets travel
through a significant typo in 2nd bullet (more ->
less)

o Section 6.3: corrected pre-congested PCN-node.

2. under-admission: a new flow is blocked (because the pre-
congestion level measured by the PCN-egress-node is
sufficiently increased by PCN-marked packets from pre-
congested paths that a couple of significant typos in Figure 2

o Section 6.5 (PCN-traffic) re-written for clarity. Non PCN-traffic
contributing to PCN meters new flow is now given as blocked), but its packets
travel along an example (there may
be cases where don't need to meter it).

o Section 7.7: added to the text about encapsulation being done
within the PCN-domain: "Note: A tunnel will not provide this
behaviour if it complies with [RFC3168] tunnelling in either mode, uncongested path.

3. ineffective termination: a flow is terminated but it will if it complies with [RFC4301] IPSec tunnelling."

o Section 7.7: added mention of [RFC4301] to the text about
decapsulation being done within the PCN-domain.

o Section 8: deleted its path
doesn't travel through the text about design goals, since this (pre-)congested router(s). Since
flow termination is
already covered adequately earlier eg in S3.

Eardley (Editor) Expires October 9, 2009 [Page 45]

Internet-Draft PCN Architecture April 2009

o Section 11: replaced a "last resort", which protects the last sentence of bullet 1 by "There
network should over-admission occur, this problem is
nothing specific probably
more important to PCN." solve than the other two.

o Appendix: added to open issues: possibility of automatically ECMP and
periodically probing.

o References: Split out Normative references (RFC2474 & RFC3246).

12.7. Changes from -04 to -05

Minor nits removed as follows:

o Further minor changes to reflect that baseline encoding Signalling: It is
consensus, standards track document, whilst there can be
(experimental track) encoding extensions

o Traffic conditioning updated to reflect discussions in Dublin,
mainly that PCN-interior-nodes don't police PCN-traffic (so
deleted bullet possible that, in S7.1) and that it is not advised to have non
PCN-traffic that shares a PCN-domain running
ECMP, the same capacity (on signalling packets (eg, RSVP, NSIS) follow a link) as PCN-
traffic (so added bullet in S6.5)

o Probing moved into Appendix A and deleted different
path than the 'third viewpoint'
(admission control based data packets, which could matter if the signalling
packets are used as probes. Whether this is an issue depends on
which fields the marking of a single packet like an
RSVP PATH message) - since this isn't really probing, and in any
case ECMP algorithm uses; if the ECMP algorithm is already mentioned in S6.1.

o Minor changes
restricted to S9 Operations the source and destination IP addresses, then it
will not be an issue. ECMP and signalling interactions are a
specific instance of a general issue for non-traditional routing
combined with resource management - mainly to reflect
that consensus on marking behaviour has simplified things so eg
there along a path [Hancock02].

Eardley Informational [Page 38]

RFC 5559 PCN Architecture June 2009

o Tunnelling: There are fewer parameters scenarios where tunnelling makes it
difficult to configure.

o A few terminology-related errors expunged, determine the path in the PCN-domain. The problem,
its impact, and two pictures added the potential solutions are similar to help. those for
ECMP.

o Re-phrased Scenarios with only one tunnel endpoint in the claim about PCN-domain: Such
scenarios may make it harder for the natural decision point in S7.4

o Clarified that extended encoding schemes need PCN-egress-node to explain their
interactions with (or assumptions about) tunnelling (S7.7) and how
they meet gather
from the guidelines signalling messages (eg, RSVP, NSIS) the identity of BCP124 (S6.6)

o Corrected the third bullet in S6.2 (to reflect consensus about
PCN-marking)

12.8. Changes from -03 to -04
PCN-ingress-node.

o Minor changes throughout to reflect the consensus Bi-Directional Sessions: Many applications have bi-directional
sessions -- hence, there are two microflows that should be
admitted (or terminated) as a pair -- for instance, a bi-
directional voice call about PCN-
marking (as reflected only makes sense if microflows in [PCN08-2]).

Eardley (Editor) Expires October 9, 2009 [Page 46]

Internet-Draft both
directions are admitted. However, the PCN Architecture April 2009

o Minor changes throughout to reflect mechanisms concern
admission and termination of a single flow, and coordination of
the decision for both flows is a matter for the current decisions about
encoding (as reflected in [PCN08-1] and [Moncaster08]).

o Introduction: re-structured to create new sections on Benefits,
Deployment scenarios signalling
protocol and Assumptions. out of scope for PCN. One possible example would use
SIP pre-conditions. However, there are others.

o Introduction: Added pointers to other Global Coordination: PCN documents.

o Terminology: changed PCN-lower-rate to PCN-threshold-rate makes its admission decision based on
PCN-markings on a particular ingress-egress-aggregate. Decisions
about flows through a different ingress-egress-aggregate are made
independently. However, one can imagine network topologies and PCN-
upper-rate
traffic matrices where, from a global perspective, it would be
better to PCN-excess-rate; excess-rate-marking make a coordinated decision across all the ingress-
egress-aggregates for the whole PCN-domain. For example, to excess-
traffic-marking.

o Benefits: added bullet about SRLGs. block
(or even terminate) flows on one ingress-egress-aggregate so that
more important flows through a different ingress-egress-aggregate
could be admitted. The problem may well be relatively
insignificant.

o Deployment scenarios: new section combining material from various
places within Aggregate Traffic Characteristics: Even when the document.

o S6 (high number of flows
is stable, the traffic level functional architecture): re-structured and edited
to improve clarity, and reflect through the latest PCN-marking and
encoding drafts.

o S6.4: added claim that PCN-domain will vary
because the most natural place to make an admission
decision sources vary their traffic rates. PCN works best when
there is not too much variability in the total traffic level at a PCN-egress-node.

o S6.5: updated
PCN-node's interface (ie, in the bullet about non-PCN-traffic aggregate traffic from all
sources). Too much variation means 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.

12.9. Changes from -02 node may (at one
moment) not be doing any PCN-marking and then (at another moment)
drop packets because it is overloaded. This makes it hard to -03

o Abstract: Clarified by removing tune
the term 'aggregated'. Follow-up
clarifications later in draft: S1: expanded PCN-egress-nodes
bullet admission control scheme to mention case where stop admitting new flows at the PCN-feedback-information
right time. Therefore, the problem is about
one (or a few) PCN-marks, rather than aggregated information; S3
clarified PCN-meter; S5 minor changes; conclusion. more likely with fewer,
burstier flows.

o S1: added Flash crowds and Speed of Reaction: PCN is a paragraph about how the PCN-domain looks to the
outside world (essentially it looks like measurement-based
mechanism and so there is an inherent delay between packet marking
by PCN-interior-nodes and any admission control reaction at PCN-
boundary-nodes. For example, if a Diffserv domain). big burst of admission requests

Eardley (Editor) Expires October 9, 2009 Informational [Page 47]

Internet-Draft 39]

RFC 5559 PCN Architecture April June 2009

o S2: tweaked the PCN-traffic terminology bullet: changed PCN
traffic classes to PCN behaviour aggregates, to be more in line
with traditional Diffserv jargon (-> follow-up changes later

potentially occurs in
draft); included a definition very short space of PCN-flows (and corrected time (eg, prompted by
a couple televote), they could all get admitted before enough PCN-marks
are seen to block new flows. In other words, any additional load
offered within the reaction time of 'PCN microflows' the mechanism must not move
the PCN-domain directly from a no congestion state to 'PCN-flows' later in draft)

o S3.5: added possibility overload.
This "vulnerability period" may have an impact at the signalling
level, for instance, QoS requests should be rate-limited to bound
the number of downgrading requests able to best effort, where PCN-
packets arrive at PCN-ingress-node already ECN marked (CE or ECN
nonce) within the vulnerability
period.

o S4: added note about whether talk about PCN operating on an
interface or on Silent at Start: After a link. In S8.1 (OAM) mentioned that PCN
functionality needs successful admission request, the source
may wait some time before sending data (eg, waiting for the called
party to answer). Then the risk is that, in some circumstances,
PCN's measurements underestimate what the pre-congestion level
will be configured consistently on either when the
ingress or source does start sending data.

7. Security Considerations

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

o S5.2: clarified Because PCN-boundary-nodes are flow-aware, they are trusted to use
that signalling protocol installs flow filter spec
at PCN-ingress-node (& updates after possible re-route)

o S5.6: addressing: clarified

o S5.7: added tunnelling issue awareness correctly. The degree of N^2 scaling if you set up a mesh trust required depends on
the kinds of tunnels between PCN-boundary-nodes

o S7.3: Clarified decisions they have to make and the "third viewpoint" kinds of probing (always probe).
information they need to make them. There is nothing specific to
PCN.

o S8.1: clarified The PCN-ingress-nodes police packets to ensure a PCN-flow sticks
within its agreed limit, and to ensure that SNMP is only an example; added note PCN-flows that an
operator may be able
have been admitted contribute PCN-traffic into the PCN-domain.
The policer must drop (or perhaps downgrade to not run PCN on some PCN-interior-nodes, if
it knows that these links will never become (pre-)congested; added
note a different DSCP)
any PCN-packets received that it may be possible are outside this remit. This is
similar to have different PCN-boundary-node
behaviours for different ingress-egress-aggregates within the same
PCN-domain.

o Appendix: Created an Appendix about "Possible work items beyond existing IntServ behaviour. Between them, the scope of PCN-
boundary-nodes must encircle the PCN-domain; otherwise, PCN-
packets could enter the PCN-domain without being subject to
admission control, which would potentially destroy the current PCN WG Charter". Material moved from
near start QoS of S3 and elsewhere throughout draft. Moved text about
centralised decision node to Appendix.

o Other minor clarifications.

12.10. Changes from -01 to -02
existing flows.

o S1: Benefits: provisioning bullet extended to stress that PCN does PCN-interior-nodes are not use RFC2475-style traffic conditioning.

o S1: Deployment models: mentioned, as variant of PCN-domain
extending to end nodes, that may extend to LAN edge switch. flow-aware. This prevents some
security attacks where an attacker targets specific flows in the
data plane -- for instance, for DoS or eavesdropping.

Eardley (Editor) Expires October 9, 2009 Informational [Page 48]

Internet-Draft 40]

RFC 5559 PCN Architecture April June 2009

o S3.1: Trust Assumption: added note about not needing The PCN-boundary-nodes rely on correct PCN-marking
capability if known by the PCN-
interior-nodes. For instance, a rogue PCN-interior-node could
PCN-mark all packets so that an interface cannot become no flows were admitted. Another
possibility is that it doesn't PCN-mark any packets, even when it
is pre-congested.

o S4: now divided into sub-sections

o S4.1: Admission control: added second proposed method for how to
decide to block new More subtly, the rogue PCN-interior-node could
perform these attacks selectively on particular flows, or it could
PCN-mark the correct fraction overall but carefully choose which
flows (PCN-egress-node receives one (or
several) PCN-marked packets). it marked.

o S5: Probing sub-section removed. Material now The PCN-boundary-nodes should be able to deal with DoS attacks and
state exhaustion attacks based on fast changes in new S7.

o S5.6: Addressing: clarified how PCN-ingress-node can discover
address of PCN-egress-node per-flow
signalling.

o S5.6: Addressing: centralised node case, added The signalling between the PCN-boundary-nodes must be protected
from attacks. For example, the recipient needs to validate that PCN-ingress-
the message is indeed from the node that claims to have sent it.
Possible measures include digest authentication and protection
against replay and man-in-the-middle attacks. For the RSVP
protocol specifically, hop-by-hop authentication is in [RFC2747],
and [Behringer09] may need to know address of PCN-egress-node

o S5.8: Tunnelling: added case of "partially PCN-capable tunnel" also be useful.

Operational security advice is given in Section 5.5.

8. Conclusions

This document describes a general architecture for flow admission and
degraded bullet
termination based on this pre-congestion information, in S6 (Open Issues)

o S7: Probing: new section. Much more comprehensive than old S5.5.

o S8: Operations and Management: substantially revised.

o other minor changes not affecting semantics

12.11. Changes from -00 to -01

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

o S1: Benefits: added one about provisioning (and contrast with quality of service of established, inelastic flows within a
single Diffserv SLAs)

o S1: Benefits: clarified that the objective domain. The main topic is the functional
architecture. This document also to stop PCN-
packets being significantly delayed (previously only mentioned not
dropping packets)

o S1: Deployment models: added one where policing mentions other topics like the
assumptions and open issues associated with the PCN architecture.

9. Acknowledgements

This document is done at ingress a revised version of access network an earlier individual working
draft authored by: P. Eardley, J. Babiarz, K. Chan, A. Charny, R.
Geib, G. Karagiannis, M. Menth, and not at ingress of PCN-domain (assume trust
between networks)

o S1: Deployment models: corrected MPLS-TE T. Tsou. They are therefore
contributors to MPLS

o S2: Terminology: adjusted definition of PCN-domain

o S3.5: Other assumptions: corrected, so that two assumptions (PCN-
nodes not performing ECN and PCN-ingress-node discarding arriving this document.

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

Eardley (Editor) Expires October 9, 2009 Informational [Page 49]

Internet-Draft 41]

RFC 5559 PCN Architecture April June 2009

CE packet) only apply if the PCN WG decides

David Ward, Lars Westberg, Magnus Westerlund, and Delei Yu. Thanks
to encode PCN-marking
in Bob Briscoe who extensively revised the ECN-field.

o S4 & S5: changed PCN-marking algorithm to marking behaviour

o S4: clarified that PCN-interior-node functionality applies for
each outgoing interface, Operations and added clarification: "The
functionality is also done by PCN-ingress-nodes for their outgoing
interfaces (ie those 'inside' the PCN-domain)."

o S4 (near end): altered to say that a PCN-node "should" dedicate
some capacity to lower priority traffic so that it isn't starved
(was "may")

o S5: clarified to say that PCN functionality Management
section.

This document is done on an
'interface' (rather than on a 'link')

o S5.2: deleted erroneous mention of service level agreement

o S5.5: Probing: re-written, especially to distinguish probing to
test the ingress-egress-aggregate from probing to test a
particular ECMP path.

o S5.7: Addressing: added mention result of probing; added that discussions in the case
where traffic is always tunnelled across the PCN-domain, add a
note that he PCN-ingress-node needs to know the address of the
PCN-egress-node.

o S5.8: Tunnelling: re-written, especially to provide a clearer
description of copying on tunnel entry/exit, by adding explanation
(keeping tunnel encaps/decaps PCN WG and PCN-marking orthogonal),
deleting one bullet ("if
forerunner activity in the inner header's marking state is more
sever then it is preserved" - shouldn't happen), and better
referencing of other IETF documents.

o S6: Open issues: stressed that "NOTE: Potential solutions are out TSVWG. A number of scope for this document" previous drafts were
presented to TSVWG; their authors were: B. Briscoe, P. Eardley, D.
Songhurst, F. Le Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley,
G. Karagiannis, A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G.
Liu, and edited a couple of sentences that
were close to solution space.

o S6: Open issues: added one about scenarios with only one tunnel
endpoint A. Bhargava.

The admission control mechanism evolved from the work led by Martin
Karsten on the Guaranteed Stream Provider developed in the PCN domain .

o S6: Open issues: ECMP: added under-admission as another potential
risk

o S6: Open issues: added one about "Silent at start"

Eardley (Editor) Expires October 9, 2009 [Page 50]

Internet-Draft PCN Architecture April 2009

o S10: Conclusions: a small conclusions section added

13. M3I
project [Karsten02] [M3I], which in turn was based on the theoretical
work of Gibbens and Kelly [Gibbens99].

10. References

13.1.

10.1. Normative References

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

[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V.,
and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop (Per-
Hop Behavior)", RFC 3246, March 2002.

13.2.

10.2. Informative References

[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.

[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.

[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Controlled-
Load Network Element Service", RFC 2211,
September 1997.

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

Eardley Informational [Page 42]

RFC 5559 PCN Architecture June 2009

[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747,
January 2000.

[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A
Framework for Policy-based Admission Control",
RFC 2753, January 2000.

[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.

[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F.,
Zhang, L., Speer, M., Braden, R., Davie, B.,
Wroclawski, J., and E. Felstaine, "A Framework for
Integrated Services Operation over Diffserv
Networks", RFC 2998, November 2000.

Eardley (Editor) Expires October 9, 2009 [Page 51]

Internet-Draft PCN Architecture April 2009

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN)
to IP", RFC 3168, September 2001.

[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J.
Heinanen, "Multi-
Protocol "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270,
May 2002.

[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay
Variation Metric for IP Performance Metrics (IPPM)",
RFC 3393, November 2002.

[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks",
STD 62, RFC 3411, December 2002.

[RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004.

[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements",
RFC 4216, November 2005.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.

Eardley Informational [Page 43]

RFC 5559 PCN Architecture June 2009

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

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
and M. Zekauskas, "A One-way Active Measurement
Protocol (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
Internet Service Provider Environments", RFC 4778,
January 2007.

[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit
Congestion

Eardley (Editor) Expires October 9, 2009 [Page 52]

Internet-Draft PCN Architecture April 2009 Marking in MPLS", RFC 5129, January 2008.

[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label
Switching (MPLS) Label Stack Entry: "EXP" Field
Renamed to "Traffic Class" Field", RFC 5462,
February 2009.

[P.800] "Methods for subjective determination of
transmission quality", ITU-T Recommendation P.800,
August 1996.

[Y.1541] "Network Performance Objectives for IP-based
Services", ITU-T Recommendation Y.1541,
February 2006.

[PCN08-1] "Baseline Encoding and Transport of Pre-Congestion
Information (work in progress)", Oct 2008.

[PCN08-2] "Metering and marking behaviour of PCN-nodes (work in
progress)", Oct 2008.

[PWE3-08] "Pseudowire Congestion Control Framework (work in
progress)", May 2008.

[Babiarz06] Babiarz, J., Chan, K., Karagiannis, G., and P.
Eardley, "SIP Controlled Admission and Preemption (work Preemption",
Work in
progress)", Oct Progress, October 2006.

[Behringer07]

[Behringer09] Behringer, M. and F. Le Faucheur, "Applicability of
Keying Methods for RSVP Security (work Security", Work in progress)", Nov 2007. Progress,
March 2009.

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

[Briscoe08-1]

Eardley Informational [Page 44]

RFC 5559 PCN Architecture June 2009

[Briscoe08] Briscoe, B., "Emulating Border Flow Policing using
Re-PCN on Bulk Data
(work Data", Work in progress)", Sept Progress,
September 2008.

[Briscoe08-2]

[Briscoe09] Briscoe, B., "Tunnelling of Explicit Congestion Notification (work
Notification", Work in
progress)", July Progress, March 2009.

[Bryant08] Bryant, S., Davie, B., Martini, L., and E. Rosen,
"Pseudowire Congestion Control Framework", Work
in Progress, May 2008.

[Charny07-1] Charny, A., Babiarz, J., Menth, M., and X. Zhang,
"Comparison of Proposed PCN Approaches (work Approaches", Work
in
progress)", Progress, November 2007.

[Charny07-2] Charny, A., Zhang, X., Le Faucheur, F., and V.
Liatsos, "Pre-Congestion Notification Using Single
Marking for

Eardley (Editor) Expires October 9, 2009 [Page 53]

Internet-Draft PCN Architecture April 2009 Admission and Termination (work Termination", Work
in progress)", Progress, November 2007.

[Charny07-3] Charny, A., "Email to PCN WG mailing list",
November 2007, <http://
www1.ietf.org/mail-archive/web/pcn/current/msg00871.html>. <http://www1.ietf.org/mail-archive/
web/pcn/current/msg00871.html>.

[Charny08] Charny, A., "Email to PCN WG mailing list",
March 2008, <http://
www1.ietf.org/mail-archive/web/pcn/current/msg01359.html>. <http://www1.ietf.org/mail-archive/web/
pcn/current/msg01359.html>.

[Eardley07] Eardley, P., "Email to PCN WG mailing list",
October 2007, <http://
www1.ietf.org/mail-archive/web/pcn/current/msg00831.html>. <http://www1.ietf.org/mail-archive/
web/pcn/current/msg00831.html>.

[Eardley09] Eardley, P., "Metering and marking behaviour of PCN-
nodes", Work in Progress, May 2009.

[Gibbens99] Gibbens, R. and F. Kelly, "Distributed connection
acceptance control for a connectionless network",
Proceedings International Teletraffic Congress
(ITC16), Edinburgh, pp. 941-952, 1999.

[Hancock02] Hancock, R. and E. Hepworth, "Slide 14 of 'NSIS: An
Outline Framework for QoS Signalling'", May 2002, <http://www-nrc.nokia.com/sua/
nsis/interim/nsis-framework-outline.ppt>. <h
ttp://www-nrc.nokia.com/sua/nsis/interim/
nsis-framework-outline.ppt>.

Eardley Informational [Page 45]

RFC 5559 PCN Architecture June 2009

[Iyer03] Iyer, S., Bhattacharyya, S., Taft, N., and C. Diot,
"An approach to alleviate link overload as observed
on an IP backbone", IEEE INFOCOM , INFOCOM, 2003,
<http://www.ieee-infocom.org/2003/papers/10_04.pdf>.

[Karsten02] Karsten, M. and J. Schmitt, "Admission Control Based
on Packet Marking and Feedback Signalling --
Mechanisms, Implementation and Experiments", TU-
Darmstadt Technical Report TR-KOM-2002-03, May 2002,
<http://www.kom.e-technik.tu-darmstadt.de/
publications/abstracts/KS02-5.html>.

[Kumar01] Kumar, A., Rastogi, R., Silberschatz, A., and B.
Yener, "Algorithms for Provisioning Virtual Private
Networks in the Hose Model", Proceedings ACM SIGCOMM
(ITC16), , 2001.

[Lefaucheur06] Le Faucheur, F., Charny, A., Briscoe, B., Eardley,
P., Babiarz, J., and K. Chan, "RSVP Extensions for
Admission Control over Diffserv using Pre-congestion
Notification (PCN) (work (PCN)", Work in progress)", Progress, June 2006.

[Menth07] "PCN-Based Resilient Network Admission Control: The Impact
of a Single Bit"", Technical Report , 2007, <http://
www3.informatik.uni-wuerzburg.de/staff/menth/Publications/
Menth07-PCN-Config.pdf>.

[M3I] "M3I - Market Managed Multiservice Internet",
<http://www.m3iproject.org/>.

[Menth08-1] Menth, M., Lehrieder, F., Eardley, P., Charny, A.,
and J. Babiarz, "Edge-Assisted Marked Flow Termination (work
Termination", Work in
progress)", Progress, February 2008.

[Menth08-2] Menth, M., Babiarz, J., Moncaster, T., and B.
Briscoe, "PCN Encoding for Packet-Specific Dual
Marking (PSDM)
(work (PSDM)", Work in progress)", Progress, July 2008.

[Menth08-3]
"PCN-Based

[Menth09-1] Menth, M. and M. Hartmann, "Threshold Configuration
and Routing Optimization for PCN-Based Resilient
Admission Control", Computer Networks, 2009,
<http://dx.doi.org/10.1016/j.comnet.2009.01.013>.

[Menth09-2] Menth, M., Lehrieder, F., Briscoe, B., Eardley, P.,
Moncaster, T., Babiarz, J., Chan, K., Charny, A.,
Karagiannis, G., Zhang, X., Taylor, T., Satoh, D.,
and R. Geib, "A Survey of PCN-Based Admission
Control and Flow Termination", 2008,
<http://www3.informatik.uni-wuerzburg.de/staff/menth/
Publications/Menth08-PCN-Comparison.pdf>.

[Moncaster08] IEEE
Communications Surveys and Tutorials, <http://
www3.informatik.uni-wuerzburg.de/staff/menth/
Publications/papers/Menth08-PCN-Overview.pdf>>.

Eardley (Editor) Expires October 9, 2009 Informational [Page 54]

Internet-Draft 46]

RFC 5559 PCN Architecture April June 2009

[Moncaster09-1] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion
Information", Work in Progress, May 2009.

[Moncaster09-2] Moncaster, T., Briscoe, B., and M. Menth, "A three state extended PCN
encoding scheme (work using 2 DSCPs to provide 3 or more states",
Work in
progress)", June 2008. Progress, April 2009.

[Sarker08] Sarker, Z. and I. Johansson, "Usecases and Benefits
of end to end ECN support in PCN
Domains (work Domains", Work
in progress)", Progress, November 2008.

[Songhurst06] Songhurst, DJ., Eardley, P., Briscoe, B., Di Cairano
Gilfedder, C., and J. Tay, "Guaranteed QoS Synthesis
for Admission Control with Shared Capacity", BT
Technical Report TR-CXR9-2006-001, Feburary 2006, <http://www.cs.ucl.ac.uk/staff/B.Briscoe/
projects/ipe2eqos/gqs/papers/GQS_shared_tr.pdf>.

[Style] "Guardian Style", Note: This document uses the
abbreviations 'ie' and 'eg' (not 'i.e.'
<http://www.cs.ucl.ac.uk/staff/
B.Briscoe/projects/ipe2eqos/gqs/papers/
GQS_shared_tr.pdf>.

[Taylor09] Charny, A., Huang, F., Menth, M., and 'e.g.'), as T. Taylor,
"PCN Boundary Node Behaviour for the Controlled Load
(CL) Mode of Operation", Work in
many style guides, eg, 2007,
<http://www.guardian.co.uk/styleguide/>. Progress,
March 2009.

[Tsou08] Tsou, T., Huang, F., and T. Taylor, "Applicability
Statement for the Use of Pre-Congestion Notification
in a Resource-Controlled Network (work Network", Work in
progress)", Progress,
November 2008.

[Westberg08] Westberg, L., Bhargava, A., Bader, A., Karagiannis,
G., and H. Mekkes, "LC-PCN: The Load Control PCN Solution (work
Solution", Work in
progress)", Progress, November 2008.

Eardley Informational [Page 47]

RFC 5559 PCN Architecture June 2009

Appendix A. Possible future work items Future Work Items

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

NOTE: it

Note: It should be crystal clear that this section discusses
possibilities only.

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

o a A single PCN-domain encompasses several autonomous systems that do
not trust each other, perhaps by using other. A possible solution is a mechanism like re-PCN,
[Briscoe08-1]. re-
PCN [Briscoe08].

o not Not all the nodes run PCN. For example, the PCN-domain is a
multi-site enterprise network. The sites are connected by a VPN
tunnel; although PCN doesn't operate inside the tunnel, the PCN

Eardley (Editor) Expires October 9, 2009 [Page 55]

Internet-Draft PCN Architecture April 2009
mechanisms still work properly because of the good QoS on the
virtual link (the tunnel). Another example is that PCN is
deployed on the general Internet (ie (ie, widely but not universally
deployed).

o applying Applying the PCN mechanisms to other types of traffic, ie ie, beyond
inelastic traffic. For traffic -- for instance, applying the PCN mechanisms to
traffic scheduled with the Assured Forwarding per-hop behaviour.
One example could be flow-rate adaptation by elastic applications
that adapt according to the pre-congestion information.

o the The aggregation assumption doesn't hold, because the link capacity
is too low. Measurement-based admission control is less accurate,
with a greater risk of over-admission for instance.

o the The applicability of PCN mechanisms for emergency use (911, GETS,
WPS, MLPP, etc.) etc.).

Other possibilities include:

o Probing. This is discussed in Section Appendix A.1 below.

o The PCN-domain extends to the end users. The This scenario is
described in [Babiarz06]. The end users need to be trusted to do
their own policing. If there is sufficient traffic, then the
aggregation assumption may hold. A variant is that the PCN-domain
extends out as far as the LAN edge switch.

Eardley Informational [Page 48]

RFC 5559 PCN Architecture June 2009

o indicating Indicating pre-congestion through signalling messages rather than
in-band (in the form of PCN-marked packets) packets).

o the The decision-making functionality is at a centralised node rather
than at the PCN-boundary-nodes. This requires that the PCN-
egress-node signals PCN-feedback-information to the centralised
node, and that the centralised node signals to the PCN-ingress-
node the decision about admission (or termination). It Such
possibility may need the centralised node and the PCN-boundary-nodes PCN-boundary-
nodes to be configured with each other's addresses. The
centralised case is described further in [Tsou08].

o Signalling extensions for specific protocols (eg RSVP, NSIS). For
example: (eg, RSVP and NSIS)
-- for example, the details of how the signalling protocol
installs the flowspec at the PCN-ingress-node for an admitted PCN-flow; PCN-
flow, and how the signalling protocol carries the PCN-feedback-information. PCN-feedback-
information. Perhaps also for other functions such as: as for coping
with failure of a PCN-boundary-node ([Briscoe06] considers what
happens if RSVP is the QoS signalling protocol); protocol) and for
establishing a tunnel across the PCN-domain if it is necessary to
carry ECN marks transparently.

Eardley (Editor) Expires October 9, 2009 [Page 56]

Internet-Draft PCN Architecture April 2009

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
traffic on its behalf.

o PCN for Pseudowire: Pseudowire. PCN may be used as a congestion avoidance
mechanism for edge to edge edge-to-edge pseudowire emulations [PWE3-08]. [Bryant08].

o PCN for MPLS: MPLS. [RFC3270] defines how to support the Diffserv
architecture in MPLS networks (Multi-protocol label switching). (Multiprotocol Label Switching) networks.
[RFC5129] describes how to add PCN for admission control of
microflows into a set of MPLS aggregates. PCN-marking is done in
MPLS's EXP field (which [RFC5462] re-names the Class of Service
(CoS) field).

o PCN for Ethernet: Ethernet. Similarly, it may be possible to extend PCN
into Ethernet networks, where PCN-marking is done in the Ethernet
header. NOTE: Note: Specific consideration of this extension is outside
of the IETF's remit.

Eardley Informational [Page 49]

RFC 5559 PCN Architecture June 2009

A.1. Probing

A.1.1. Introduction

Probing is a potential mechanism to assist admission control.

PCN's admission control, as described so far, is essentially a
reactive mechanism where the PCN-egress-node monitors the pre-
congestion level for traffic from each PCN-ingress-node; if the level
rises
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
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'
"empty" ingress-egress-aggregate adds extra traffic onto a link that
is already pre-congested - which pre-congested. This 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 configuring, on each link link, a
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

Eardley (Editor) Expires October 9, 2009 [Page 57]

Internet-Draft PCN Architecture April 2009
probing: a PCN-ingress-node generates and sends probe packets in
order to test the pre-congestion level that the flow would
experience.

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

A.1.2. Probing functions Functions

The probing functions are:

o Make the decision that probing is needed. As described above,
this is when the ingress-egress-aggregate (or the ECMP path - -- see
Section 6.4) carries no PCN-traffic. An alternative is always to always
probe, ie ie, probe before admitting every any PCN-flow.

Eardley Informational [Page 50]

RFC 5559 PCN Architecture June 2009

o (if required) Communicate the request that probing is needed - needed; the
PCN-egress-node signals to the PCN-ingress-node that probing is
needed
needed.

o (if required) Generate probe traffic - traffic; the PCN-ingress-node
generates the probe traffic. The appropriate number (or rate) of
probe packets will depend on the PCN-metering algorithm; for
example
example, an excess-traffic-metering algorithm triggers fewer PCN-
marks than a threshold-metering algorithm, and so will need more
probe packets.

o Forward probe packets - packets; as far as PCN-interior-nodes are concerned,
probe packets are handled the same as (ordinary data)
PCN-packets, PCN-packets
in terms of routing, scheduling scheduling, and PCN-marking.

o Consume probe packets - packets; the PCN-egress-node consumes probe packets
to ensure that they don't travel beyond the PCN-domain.

A.1.3. Discussion of rationale Rationale for probing, its downsides Probing, Its Downsides and open
issues Open
Issues

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

The first viewpoint assumes the following:

Eardley (Editor) Expires October 9, 2009 [Page 58]

Internet-Draft PCN Architecture April 2009

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, [Eardley07] suggests that, during the future
busy hour of a national network with about 100 PCN-boundary-nodes,
there are likely to be significant numbers of aggregates with very
few flows under nearly all circumstances.

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

Eardley Informational [Page 51]

RFC 5559 PCN Architecture June 2009

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 -- and, in the flash crowd scenario
scenario, there will be probing on many ingress-egress-aggregates.

The second viewpoint applies in the case where there is multipath
routing (ECMP) (eg, 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

* There's a significant chance that the traffic is unevenly
balanced across the ECMP paths, and hence 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 of
blocking a flow that should be admitted.

Note: [Charny07-3] suggests unbalanced traffic is quite
possible, even with quite a large number of flows on a PCN-link (eg 1000)
(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

Eardley (Editor) Expires October 9, 2009 [Page 59]

Internet-Draft PCN Architecture April 2009 assumes:

* There is no PCN-traffic on the ECMP path on which to base an
admission decision.

* Simply admitting the new flow has a significant risk of
leading to overload.

* The PCN-egress-node can match a packet to an ECMP path.

Note: This is similar to the first viewpoint and so similarly so, similarly,
could occur in a flash crowd if a new flow starts more-or-less 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, PCN-boundary-nodes,
it's presumably more likely that an ECMP path is
'empty' "empty" than an
ingress-egress-aggregate is. To constrain the number of ECMP
paths, a few tunnels could be set-up set up between each pair of PCN-boundary-nodes. PCN-

Eardley Informational [Page 52]

RFC 5559 PCN Architecture June 2009

boundary-nodes. Tunnelling also solves the issue in the bullet point
immediately above (which is otherwise hard to solve 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, since they might confuse
the destination end node. This is non-trivial, since probe
packets are addressed to the destination end node, node in order to test
the relevant ECMP path (ie (ie, they are not addressed to the PCN-
egress-node, unlike the first viewpoint above).

The open issues associated with this viewpoint these viewpoints include:

o What rate and pattern of probe packets does the PCN-ingress-node
need to generate, generate so that there's enough traffic to make the
admission decision?

o What difficulty does the delay (whilst probing is done), and
possible packet drops, cause applications?

o Can the delay be alleviated by automatically and periodically
probing on the ingress-egress-aggregate? Or does this add too

Eardley (Editor) Expires October 9, 2009 [Page 60]

Internet-Draft PCN Architecture April 2009
much overhead?

o Are there other ways of dealing with the flash crowd scenario?
For instance, by limiting the rate at which new flows are
admitted;
admitted, or perhaps by a PCN-egress-node blocking new flows on
its empty ingress-egress-aggregates when its non-empty ones are
pre-congested.

o (Second viewpoint only) How does the PCN-egress-node disambiguate
probe packets from data packets (so it can consume the former)?
The PCN-egress-node must match the characteristic setting of
particular bits in the probe packet's header or body - body, but these
bits must not be used by any PCN-interior-node's ECMP algorithm.
In the general case case, this isn't possible, but it should be
possible for a typical ECMP algorithm (which examines: examines the source
and destination IP addresses and port numbers, the protocol ID,
and the DSCP).

Eardley Informational [Page 53]

RFC 5559 PCN Architecture June 2009

Author's Address

Philip Eardley (editor)
BT
B54/77, Sirius House Adastral Park Martlesham Heath
Ipswich, Suffolk IP5 3RE
United Kingdom

Email:

EMail: philip.eardley@bt.com

Eardley (Editor) Expires October 9, 2009 Informational [Page 61] 54]

----