WDIFF

draft-ietf-pcn-architecture-09.txt --> draft-ietf-pcn-architecture-10.txt

Congestion and Pre-Congestion Philip. Eardley (Editor)
Notification Working Group BT
Internet-Draft January 14, March 16, 2009
Intended status: Informational
Expires: July 18, September 17, 2009

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

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. 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 July 18, September 6, 2009.

Eardley (Editor) Expires September 17, 2009 [Page 1]

Internet-Draft PCN Architecture March 2009

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

Eardley (Editor) Expires July 18, 2009 [Page 1]

Internet-Draft PCN Architecture January 2009

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 inelastic flows within a single
DiffServ domain.

Eardley (Editor) Expires September 17, 2009 [Page 2]

Internet-Draft PCN Architecture March 2009

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . 5
1.1. Applicability of PCN . . . . . . . . . . . . . . . . . . 5
1.2. Example use case for PCN . . . . . 5
3. Benefits . . . . . . . . . . . 6
1.3. Documents about PCN . . . . . . . . . . . . . . . . 7
4. Deployment scenarios . . . 9
2. Terminology . . . . . . . . . . . . . . . . . . 9
5. Assumptions and constraints on scope . . . . . . . 10
3. High-level functional architecture . . . . . . 12
5.1. Assumption 1: Trust and support of PCN - controlled
environment . . . . . . . . 12
3.1. Flow admission . . . . . . . . . . . . . . . 12
5.2. Assumption 2: Real-time applications . . . . . . 14
3.2. Flow termination . . . . . 13
5.3. Assumption 3: Many flows and additional load . . . . . . . 13
5.4. Assumption 4: Emergency use out of scope . . . . . . . . 15
3.3. Flow admission and/or flow termination when there are
only two PCN encoding states . 14
6. High-level functional architecture . . . . . . . . . . . . . 16
3.4. Information transport . 14
6.1. Flow admission . . . . . . . . . . . . . . . . . 17
3.5. PCN-traffic . . . . . 16
6.2. Flow termination . . . . . . . . . . . . . . . . . . 17
3.6. Backwards compatibility . . . 16
6.3. Flow admission and/or flow termination when there are
only two PCN encoding states . . . . . . . . . . . . . . 18
4. Detailed Functional architecture . 17
6.4. Information transport . . . . . . . . . . . . . . 18
4.1. PCN-interior-node functions . . . . 18
6.5. PCN-traffic . . . . . . . . . . . 19
4.2. PCN-ingress-node functions . . . . . . . . . . . . . . 19
6.6. Backwards compatibility . 20
4.3. PCN-egress-node functions . . . . . . . . . . . . . . . . 20
7. Detailed Functional architecture
4.4. Admission control functions . . . . . . . . . . . . . . . 20
7.1. PCN-interior-node 21
4.5. Flow termination functions . . . . . . . . . . . . . . . 21
7.2. PCN-ingress-node functions 22
4.6. Addressing . . . . . . . . . . . . . . . . 21
7.3. PCN-egress-node functions . . . . . . . 22
4.7. Tunnelling . . . . . . . . . 22
7.4. Admission control functions . . . . . . . . . . . . . . 23
4.8. Fault handling . 22
7.5. Flow termination functions . . . . . . . . . . . . . . . . 23
7.6. Addressing . . . . 25
5. Operations and Management . . . . . . . . . . . . . . . . . . 25
5.1. Configuration Operations and Management . . 24
7.7. Tunnelling . . . . . . . 25
5.1.1. System options . . . . . . . . . . . . . . . . . 25
7.8. Fault handling . . . 26
5.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . 26
8. Challenges . 27
5.2. Performance & Provisioning Operations and Management . . 28
5.3. Accounting Operations and Management . . . . . . . . . . 30
5.4. Fault Operations and Management . . . . . . . . . . . . . 27
9. 30
5.5. Security Operations and Management . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . 29
9.1. Configuration OAM . . . . . . . . . . . . . . 31
7. Security considerations . . . . . . 29
9.1.1. System options . . . . . . . . . . . . . 32
8. Conclusions . . . . . . . 30
9.1.2. Parameters . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . 31
9.2. Performance & Provisioning OAM . . . . . . . . . . . . . . 32
9.3. Accounting OAM . . . . . 33
10. Comments Solicited . . . . . . . . . . . . . . . . . 34
9.4. Fault OAM . . . . . 33
11. Changes . . . . . . . . . . . . . . . . . . . 34

Eardley (Editor) Expires July 18, 2009 [Page 2]

Internet-Draft PCN Architecture January 2009

9.5. Security OAM . . . . . . . . 34
11.1. Changes from -098 to -10 . . . . . . . . . . . . . . . 35
10. IANA Considerations . 34
11.2. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 34
11.3. Changes from -07 to -08 . . . 35
11. Security considerations . . . . . . . . . . . . . . 34
11.4. Changes from -06 to -07 . . . . . 36
12. Conclusions . . . . . . . . . . . . 35
11.5. Changes from -05 to -06 . . . . . . . . . . . . . 37
13. Acknowledgements . . . . 35
11.6. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 36
11.7. Changes from -03 to -04 . . 37
14. Comments Solicited . . . . . . . . . . . . . . . 37
11.8. Changes from -02 to -03 . . . . . . . 37
15. Changes . . . . . . . . . . 37
11.9. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 38
15.1.
11.10. Changes from -08 -00 to -09 -01 . . . . . . . . . . . . . . . . . 38
15.2. Changes from -07 to -08 39

Eardley (Editor) Expires September 17, 2009 [Page 3]

Internet-Draft PCN Architecture March 2009

12. Appendix A: Applicability of PCN . . . . . . . . . . . . . . . 41
12.1. Benefits . . 38
15.3. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 38
15.4. Changes from -05 to -06 . . . . . 41
12.2. Deployment scenarios . . . . . . . . . . . . 38
15.5. Changes from -04 to -05 . . . . . . 42
12.3. Assumptions and constraints on scope . . . . . . . . . . 44
12.3.1. Assumption 1: Trust and support of PCN -
controlled environment . 39
15.6. Changes from -03 to -04 . . . . . . . . . . . . . . . 45
12.3.2. Assumption 2: Real-time applications . . 40
15.7. Changes from -02 to -03 . . . . . . . 45
12.3.3. Assumption 3: Many flows and additional load . . . . . 46
12.3.4. Assumption 4: Emergency use out of scope . . . . . . . 46
12.4. Challenges . . . . . 41
15.8. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 42
15.9. Changes from -00 to -01 . 46
13. Appendix B: Possible future work items . . . . . . . . . . . . 49
13.1. Benefits . . . . . 43
16. Appendix: Possible future work items . . . . . . . . . . . . . 44
16.1. . . . . . . 49
13.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 46
16.1.1. 52
13.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 46
16.1.2. 52
13.2.2. Probing functions . . . . . . . . . . . . . . . . . . 47
16.1.3. 53
13.2.3. Discussion of rationale for probing, its downsides
and open issues . . . . . . . . . . . . . . . . . . . 47
17. 54
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
17.1. 56
14.1. Normative References . . . . . . . . . . . . . . . . . . . 50
17.2. 56
14.2. Informative References . . . . . . . . . . . . . . . . . . 50 56
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 54 61

Eardley (Editor) Expires July 18, September 17, 2009 [Page 3] 4]

Internet-Draft PCN Architecture January March 2009

1. Introduction

1.1. Applicability of PCN

The purpose objective of this document the Pre-Congestion Notification (PCN) mechanisms is
to describe a general architecture
for flow admission and termination based on (pre-) congestion
information in order to protect the quality of service (QoS) of flows within a DiffServ
domain [RFC2475]. This document defines an
architecture for implementing two [RFC2475], in a simple, scalable and robust fashion. Two
mechanisms are defined to protect the quality
of service QoS of established inelastic
flows within a single DiffServ domain, where all boundary and
interior nodes are PCN-enabled and are trusted for correct PCN
operation. Flow admission control determines whether a new flow
should be admitted, in order to protect the QoS of existing PCN-flows
in normal circumstances. However, in abnormal circumstances, for
instance a disaster affecting multiple nodes and causing traffic re-routes, re-
routes, then the QoS on existing PCN-flows may degrade even though
care was exercised when admitting those flows.
Therefore this document also describes a mechanism for The flow
termination, which termination
mechanism removes enough traffic in order to protect the QoS of the
remaining PCN-flows.

As a fundamental building block to enable these two

Compared with alternative QoS mechanisms, PCN-
interior-nodes generate, encode PCN has certain advantages
and transport pre-congestion
information towards disadvantages that will make it appropriate in particular
scenarios. For example, compared with hop-by-hop IntServ [RFC1633],
PCN only requires per flow state at the PCN-egress-nodes. Two rates, a PCN-
threshold-rate and a PCN-excess-rate, are associated PCN-ingress-nodes. Compared
with each link the DiffServ architecture [RFC2475], an operator needs to be
less accurate and/or conservative in its prediction of the PCN-domain. Each rate is used by a marking behaviour that
determines how traffic
matrix. The DiffServ architecture's traffic conditioning agreements
are static and when PCN-packets coarse; they are marked, defined at subscription time, and how the markings
they are encoded in packet headers. Overall the aim is to enable PCN-
nodes used to give an "early warning" limit the total traffic at each ingress of potential congestion before there
is any significant build-up the
domain regardless of PCN-packets in the queue.

PCN-boundary-nodes convert egress for the traffic. On the other hand,
PCN firstly uses admission control based on measurements of these PCN-markings into
decisions about flow admission the
current conditions between the specific pair of PCN-boundary-nodes,
and termination. In secondly, in case of a PCN-domain with
both threshold marking and excess traffic marking enabled, then disaster, PCN protects the QoS of most
flows by terminating a few selected ones.

PCN's admission control mechanism limits is a measurement-based mechanism. Hence it
assumes that the PCN-traffic on each link to
*roughly* its PCN-threshold-rate and present is a reasonable prediction of the flow termination mechanism
limits future:
the PCN-traffic on each link to *roughly* its PCN-excess-rate.
Other scenarios network conditions are discussed later.

The behaviour measured at the time of PCN-interior-nodes a new flow
request, but the actual network performance must be acceptable during
the call some time later. Hence PCN is standardised in other
documents, which are summarised unsuitable in this document: several
circumstances:

o Marking behaviour: threshold marking and excess traffic marking
[PCN08-2]. Threshold marking marks all PCN-packets if If the PCN
traffic source adapts its bit rate is greater than a first configured rate, "PCN-
threshold-rate". Excess traffic marking marks a proportion of
PCN-packets, such that dependent on the amount marked equals level of pre-
congestion, because then the aggregate traffic rate might become
unstable. The assumption in excess of a second configured rate, "PCN-excess-rate".

Eardley this document is that PCN-packets
come from real time applications generating inelastic traffic,
such as the Controlled Load Service, [RFC2211].

Eardley (Editor) Expires July 18, September 17, 2009 [Page 4] 5]

Internet-Draft PCN Architecture January March 2009

o Encoding: If a combination of the DSCP field and ECN field in the IP
header indicates that potential bottleneck link has capacity for only a packet is few flows,
because then a PCN-packet and whether new flow can move a link directly from no pre-
congestion to being so overloaded that it is
PCN-marked. has to drop packets.
The "baseline" encoding is described assumption in [PCN08-1],
which standardises two PCN encoding states (PCN-marked and not
PCN-marked), whilst (experimental) extensions to this document is that this isn't a problem.

o If there is the baseline
encoding can provide three encoding states (threshold-marked,
excess-traffic-marked, not PCN-marked, or perhaps further encoding
states as suggested danger of a "flash crowd" in [Westberg08]). PCN encoding therefore
defines semantics for the ECN field different from which many admission
requests arrive within the default
semantics reaction time of [RFC3168], PCN's admission
mechanism, because then they all might get admitted and so its encoding needs to meet
overload the
guidelines of BCP 124 [RFC4774]. network. The behaviour of PCN-boundary-nodes is described in Informational
documents. Several possibilities are outlined assumption in this document;
detailed descriptions and comparisons document is that, if
it is necessary, then flash crowds are limited in [Charny07-1] and
[Menth08-3].

This document describes some fashion
beyond the scope of this document, for instance by rate limiting
QoS requests.

The applicability of PCN architecture at a high level (Section
6) and is discussed further in more detail (Section 7). It also defines some terminology
and Appendix A.

1.2. Example use case for PCN

This section outlines some benefits, deployment scenarios, and assumptions of an end-to-end QoS scenario that uses the PCN (Sections 2-5). Finally it outlines some challenges, operations
and management, and security considerations, and some potential
future work items (Sections 8, 9, 11 and Appendix).

2. Terminology

o PCN-domain: a PCN-capable domain; a contiguous set
mechanisms within one domain. The parts outside the PCN-domain are
out of PCN-enabled
nodes scope for PCN, but are included to help clarify how PCN could
be used. Note that perform DiffServ scheduling [RFC2474]; the complete set
of PCN-nodes whose PCN-marking can section is only an example - in principle influence
decisions about flow admission and termination particular
there are other possibilities (see later) for how the PCN-domain,
including the PCN-egress-nodes, which measure these PCN-marks.

o PCN-boundary-node: a PCN-node that connects one PCN-domain to PCN-boundary-
nodes perform admission control and flow termination.

As a
node either in another fundamental building block, each link of the PCN-domain or in a non PCN-domain. operates
two PCN-marking behaviours [PCN08-2] (Figure 1):

o PCN-interior-node: a node in a PCN-domain that Threshold marking, which marks all PCN-packets if the PCN traffic
rate is not a PCN-
boundary-node.

o PCN-node: a PCN-boundary-node or a PCN-interior-node

o PCN-egress-node: greater than a PCN-boundary-node in first configured rate, the PCN-threshold-
rate. The admission control mechanism limits the PCN-traffic on
each link to *roughly* its role in handling
traffic as it leaves a PCN-domain. PCN-threshold-rate.

o PCN-ingress-node: a PCN-boundary-node in its role in handling Excess traffic as it enters marking, which marks a PCN-domain.

Eardley (Editor) Expires July 18, 2009 [Page 5]

Internet-Draft PCN Architecture January 2009

o PCN-traffic, proportion of PCN-packets, PCN-BA: a PCN-domain carries
such that the amount marked equals the traffic rate in excess of
different DiffServ behaviour aggregates (BAs) [RFC2474]. The
PCN-BA uses the PCN mechanisms to carry PCN-traffic and the
corresponding packets are PCN-packets. The same network will
carry traffic of other DiffServ BAs. The PCN-BA is distinguished
by a combination of the DiffServ codepoint (DSCP) and ECN fields.

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.

o Ingress-egress-aggregate: The collection of PCN-packets from all
PCN-flows that travel in one direction between a specific pair of
PCN-boundary-nodes.

o PCN-threshold-rate: a reference rate
second configured for each link in
the PCN-domain, which is lower than rate, the PCN-excess-rate. It is
used by a marking behaviour that determines whether a packet
should be PCN-marked with a first encoding, "threshold-marked".

o PCN-excess-rate: a reference rate configured for each link in the
PCN-domain, which is higher than the PCN-threshold-rate. It is
used by a marking behaviour that determines whether a packet
should be PCN-marked with a second encoding, "excess-traffic-
marked".

o Threshold-marking: a PCN-marking behaviour with the objective that
all PCN-traffic is marked if the PCN-traffic exceeds the PCN-
threshold-rate.

o Excess-traffic-marking: a PCN-marking behaviour with the objective
that The flow termination
mechanism limits the amount of PCN-traffic that is PCN-marked is equal on each link to the
amount that exceeds the *roughly* its
PCN-excess-rate.

o Pre-congestion: a condition of a link within a PCN-domain such
that

Overall the PCN-node performs PCN-marking, in order aim is to provide give an "early warning" of potential congestion
before there is any significant build-up of PCN-packets in the real queue. (Hence, queue
on the link; we term this "pre-congestion notification" by analogy
with ECN we call our mechanism Pre-Congestion
Notification.)

o PCN-marking: (Explicit Congestion Notification, [RFC3168]). Note that
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-colouring: the process of setting link only meters the header in a PCN-packet
by a PCN-boundary-node; performed by a PCN-ingress-node so that bulk PCN-traffic (and not per flow).

Eardley (Editor) Expires July 18, September 17, 2009 [Page 6]

Internet-Draft PCN Architecture January March 2009

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.

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

Figure 1: Example of how the PCN admission control should accept new PCN-flows.

o PCN-supportable-rate: and flow
termination mechanisms operate as the rate of PCN-traffic on a link down 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 PCN flow termination should, if necessary, terminate already
admitted PCN-flows.

3. Benefits

We believe that are configured for the key benefits of domain. Thus the PCN mechanisms described PCN-egress-
nodes can monitor the PCN-markings in
this document are that they are simple, scalable, and robust because:

o Per flow state is only required at order to measure the severity
of pre-congestion. In addition, the PCN-ingress-nodes
("stateless core"). This is required for policing purposes (to
prevent non-admitted PCN traffic from entering need to set
the PCN-domain) ECN and
so on. It is not generally required DSCP fields to 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 configured for an unmarked PCN-
packet, and the
routing system. Hence 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]) in general admitted flows can survive
capacity, routing or topology changes without additional
signalling. this example. 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 PCN-domain 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
a single RSVP hop. The PCN-marking behaviours only operate on the overall PCN-domain operates DiffServ, and we assume
that PCN-traffic
on the link, not per flow.

o The information of these measurements is signalled to the PCN-
egress-nodes by scheduled with the PCN-marks in expedited forwarding (EF) per-
hop behaviour, [RFC3246]. Hence the packet headers, ie [Style]
"in-band". No additional signalling protocol overall solution is required for
transporting in line with
the PCN-marks. Therefore no secure binding is
required between data packets and separate congestion messages. "IntServ over DiffServ" framework defined in [RFC2998], as shown
in Figure 2.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 7]

Internet-Draft PCN Architecture January March 2009

___ ___ _______________________________________ ____ ___
| | | | | PCN- PCN- PCN- | | | | |
| | | | |ingress interior egress| | | | |
| | | | | -node -nodes -node | | | | |
| | | | |-------+ +-------+ +-------+ +------| | | | |
| | | | | PCN- | | PCN- | | PCN- | | | | | | |
| |..| |..|marking|..|marking|..|marking|..| 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

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 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 to check
what fraction of the PCN-traffic, from the relevant 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
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 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; and a traffic profile, so that it can
police the flow to within its contract. Similarly, the RSVP message
triggers the PCN-egress-node to install five-tuple and PHOP
information, so that it can identify packets as part of a flow from a
specific PCN-ingress-node.

Eardley (Editor) Expires September 17, 2009 [Page 8]

Internet-Draft PCN Architecture March 2009

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

1.3. Documents about PCN

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

Aspects of PCN are also documented elsewhere:

o Marking behaviour: threshold marking and excess traffic marking
are standardised in [PCN08-2].

o Encoding: the "baseline" encoding is described in [PCN08-1], which
standardises two PCN encoding states (PCN-marked and not PCN-
marked), whilst (experimental) extensions to the baseline encoding
can provide three encoding states (threshold-marked, excess-
traffic-marked, not PCN-marked, or perhaps further encoding states
as suggested in [Westberg08]). Section 3.6 considers backwards
compatability 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. The concept is that the standardised marking
behaviours allow several possible PCN-boundary-node behaviours,
which are described in Informational documents. A number of
possibilities are outlined in this document; detailed descriptions
and comparisons are in [Charny07-1] and [Menth08-3].

o Signalling between PCN-boundary-nodes: 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 (Editor) Expires September 17, 2009 [Page 9]

Internet-Draft PCN Architecture March 2009

details vary for different PCN-boundary-node behaviours, and so
should be described in those documents. It may require an
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 whose PCN-marking can in principle influence
decisions about flow admission and termination for the PCN-domain,
including the PCN-egress-nodes, which measure these PCN-marks.

o PCN-boundary-node: a PCN-node that connects one PCN-domain to a
node either in another PCN-domain or in a non PCN-domain.

o PCN-interior-node: a node in a PCN-domain that is not a PCN-
boundary-node.

o PCN-node: a PCN-boundary-node or a PCN-interior-node

o PCN-egress-node: a PCN-boundary-node in its role in handling
traffic as it leaves a PCN-domain.

o PCN-ingress-node: a PCN-boundary-node in its role in handling
traffic as it enters a PCN-domain.

o PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic of
different DiffServ behaviour aggregates (BAs) [RFC2474]. The
PCN-BA uses the PCN mechanisms to carry PCN-traffic and the
corresponding packets are PCN-packets. The same network will
carry traffic of other DiffServ BAs. The PCN-BA is distinguished
by a combination of the DiffServ codepoint (DSCP) and ECN fields.

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

Eardley (Editor) Expires September 17, 2009 [Page 10]

Internet-Draft PCN Architecture March 2009

microflows.

o Ingress-egress-aggregate: The PCN-egress-nodes make separate measurements, operating on the
aggregate PCN-traffic collection of PCN-packets from each PCN-ingress-node, ie not per flow.
Similarly, signalling by the PCN-egress-node all
PCN-flows that travel in one direction between a specific pair of PCN-feedback-
information (which is used
PCN-boundary-nodes.

o PCN-threshold-rate: a reference rate configured for flow admission and termination
decisions) is at the granularity of each link in
the ingress-egress-aggregate.
An alternative approach PCN-domain, which is that the PCN-egress-nodes monitor lower than the
PCN-traffic and signal PCN-feedback-information (which PCN-excess-rate. It is
used for
flow admission and termination decisions) at the granularity of
one (or by a few) PCN-marks. marking behaviour that determines whether a packet
should be PCN-marked with a first encoding, "threshold-marked".

o The admitted PCN-load is controlled dynamically. Therefore it
adapts as PCN-excess-rate: a reference rate configured for each link in the traffic matrix changes, and also if
PCN-domain, which is higher than the network
topology changes (eg after PCN-threshold-rate. It is
used by a link failure). Hence an operator can marking behaviour that determines whether a packet
should be less conservative when deploying network capacity, and less
accurate in their prediction of PCN-marked with a second encoding, "excess-traffic-
marked".

o Threshold-marking: a PCN-marking behaviour with the objective that
all PCN-traffic matrix.

o The termination mechanism complements admission control. It
allows is marked if the network to recover from sudden unexpected surges of PCN-traffic on some links, thus restoring QoS to exceeds the remaining
flows. Such scenarios are expected to be rare but not impossible.
They can be caused by large network failures PCN-
threshold-rate.

o Excess-traffic-marking: a PCN-marking behaviour with the objective
that redirect lots the amount of
admitted PCN-traffic that is PCN-marked is equal to other links, or by malfunction of the
measurement-based admission control in
amount that exceeds the presence PCN-excess-rate.

o Pre-congestion: a condition of admitted
flows that send for a while with an atypically low rate and then
increase their rates in link within 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 PCN-domain such
that the PCN-node performs PCN-marking, in order to
protect against link or node failures. This provide an
"early warning" of potential congestion before there is especially any
significant build-up of PCN-packets in the
case real queue. (Hence, by
analogy 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%) ECN we call our mechanism Pre-Congestion
Notification.)

o PCN-marking: the process of setting the link bandwidth header in a PCN-packet
based on
some links before failure [Charny08]. defined rules, in reaction to pre-congestion; either
threshold-marking or excess-traffic-marking.

o The PCN-supportable-rate may be set below PCN-colouring: the maximum rate process of setting the header in a PCN-packet
by a PCN-boundary-node; performed by a PCN-ingress-node so that
PCN-traffic
PCN-nodes can be transmitted on easily identify PCN-packets; performed by a link, in order to trigger
termination of some PCN-flows before loss (or excessive delay) of
PCN-packets occurs, or to keep PCN-
egress-node so that the maximum PCN-load on header is appropriate for nodes beyond the
PCN-domain.

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

o Provisioning of the network is decoupled from PCN-admissible-rate: the process rate of
adding new customers. By contrast, with the DiffServ architecture
[RFC2475] operators rely PCN-traffic 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 link up to
verify provision is sufficient each time a which
PCN admission control should accept new customer is added PCN-flows.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 8] 11]

Internet-Draft PCN Architecture January March 2009

to check that

o PCN-supportable-rate: the Service Level Agreement can be fulfilled. A
PCN-domain doesn't need such traffic conditioning.

4. Deployment scenarios

Operators rate of networks will want PCN-traffic on a link down to use the
which PCN mechanisms in various
arrangements, flow termination should, if necessary, terminate already
admitted PCN-flows.

3. High-level functional architecture

The high-level approach is to split functionality between:

o PCN-interior-nodes 'inside' the PCN-domain, which monitor their
own state of pre-congestion and mark PCN-packets as appropriate.
They are not flow-aware, nor aware of ingress-egress-aggregates.
The functionality is also done by PCN-ingress-nodes for instance depending their
outgoing interfaces (ie those '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 how they information from PCN-interior-nodes. This information is
in the form of the PCN-marked data packets (which are performing
admission control outside intercepted
by the PCN-egress-nodes) and not signalling messages. Generally
PCN-ingress-nodes are flow-aware.

The aim of this split is to keep the bulk of the PCN-domain (users after all are
concerned about QoS end-to-end), what their particular goals network simple,
scalable and
assumptions are, how many PCN encoding states are available, robust, whilst confining policy, application-level and so
on.

From
security interactions to the perspective edge of the outside world, a PCN-domain essentially
looks like a DiffServ domain. PCN-traffic is either transported
across it transparently or policed at PCN-domain. For example the PCN-ingress-node (ie
dropped or carried at a lower QoS). One difference is
lack of flow awareness means that PCN-
traffic has better QoS guarantees than normal DiffServ traffic,
because the PCN mechanisms better protect PCN-interior-nodes don't care
about the QoS flow information associated with PCN-packets, nor do the
PCN-boundary-nodes care about which PCN-interior-nodes its ingress-
egress-aggregates traverse.

In order to generate information about the current state of admitted flows.
Another difference may occur in the rare circumstance when there PCN-
domain, each PCN-node PCN-marks packets if it is "pre-congested".
Exactly when a
failure: on the one hand some PCN-flows may get terminated, but on
the other hand other flows PCN-node decides if it is "pre-congested" (the
algorithm) and exactly how packets are "PCN-marked" (the encoding)
will get their QoS restored. Non PCN-
traffic be defined in separate standards-track documents, but at a high
level it is treated transparently, ie as follows:

o the PCN-domain is algorithms: a normal
DiffServ domain.

An operator may choose to deploy either admission control or flow
termination or both. Although designed to work together, they 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
independent mechanisms, two algorithms, one for threshold-marking and the use of one does not require or
prevent for excess-
traffic-marking.

o the use encoding(s): a PCN-node PCN-marks a PCN-packet by modifying a
combination of the other.

A PCN-domain may have three DSCP and ECN fields. In the "baseline"
encoding states (or pedantically, an
operator may choose [PCN08-1], the ECN field is set to use up three encoding states for PCN): not
PCN-marked, threshold-marked, excess-traffic-marked. Then both PCN
admission control 11 and flow termination can the DSCP is not
altered. Extension encodings may be supported. As
illustrated defined that, at most, use a
second DSCP (eg as 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 [Moncaster08]) and/or set the flow termination mechanism
terminates flows down ECN field to the PCN-excess-rate on the bottleneck link.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 9] 12]

Internet-Draft PCN Architecture January March 2009

Figure 1: Schematic of how the PCN admission control and flow
termination mechanisms operate as the rate of PCN-traffic increases,
for a PCN-domain with three encoding states.

On the

values other hand, than 11 (eg as in [Menth08-2]).

In a PCN-domain the operator may have two or three encoding states (as in
[PCN08-1]) (or pedantically, an operator may choose to use up
available. The baseline encoding provides two encoding states for PCN): not (not
PCN-marked, PCN-marked. Then there are PCN-marked), whilst extended encodings can provide three possibilities, as discussed in the following paragraphs (see
also Section 6.3).

First, an
encoding states (not PCN-marked, threshold-marked, excess-traffic-
marked).

An operator could just use PCN's may choose to deploy either admission control, solving
heavy congestion (caused by re-routing) by 'just waiting' - as
sessions end, PCN-traffic naturally reduces, control or flow
termination or both. Although designed to work together, they are
independent mechanisms, and meanwhile the
admission control mechanism will 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 flows 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-marking needs to be configured on all (potentially pre-congested)
links in the PCN-domain to ensure that
use the affected PCN mechanisms protect all
links. So 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 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 ensure that the congestion, PCN mechanisms protect all PCN-flows as well as lower priority
services will be adversely affected.

Second, an operator could just rely
links. See [PCN08-2] for admission control on
statically provisioned capacity per PCN-ingress-node (regardless further discussion.

The objective of the PCN-egress-node threshold-marking algorithm is to threshold-mark
all PCN-packets whenever the rate of a flow), as PCN-packets is typical in greater than some
configured rate, the hose model PCN-threshold-rate. The objective of

Eardley (Editor) Expires July 18, 2009 [Page 10]

Internet-Draft PCN Architecture January 2009 the DiffServ architecture [RFC2475]. Such traffic conditioning
agreements can lead
excess-traffic-marking algorithm is to focused overload: many flows happen excess-traffic-mark PCN-
packets at a rate equal to focus
on the difference between the bit rate of
PCN-packets and some configured rate, the PCN-excess-rate. Note that
this description reflects the overall intent of the algorithm rather
than its instantaneous behaviour, since the rate measured at a
particular link moment depends on the detailed algorithm, its
implementation, and then all flows through the congested link
fail catastrophically. PCN's flow termination mechanism could then
be used to counteract such traffic's variance as well as its rate (eg
marking may well continue after a problem.

Third, both admission control recent overload even after the
instantaneous rate has dropped). The algorithms are specified in
[PCN08-2].

Admission and flow termination can be triggered
from approaches are detailed and compared in
[Charny07-1] and [Menth08-3]. The discussion below is just a brief
summary. Sections 3.1 and 3.2 assume there are three encoding states

Eardley (Editor) Expires September 17, 2009 [Page 13]

Internet-Draft PCN Architecture March 2009

available, whilst Section 3.3 assumes there are two encoding states
available.

From the single type perspective of PCN-marking; the main downside outside world, a PCN-domain essentially
looks like a DiffServ domain. PCN-traffic is that
admission control either transported
across it transparently or policed at the PCN-ingress-node (ie
dropped or carried at a lower QoS). One difference is less accurate [Charny07-2].

Within that PCN-
traffic has better QoS guarantees than normal DiffServ traffic,
because the PCN-domain PCN mechanisms better protect the QoS of admitted flows.
Another difference may occur in the rare circumstance when there is a
failure: on the one hand some flexibility about how PCN-flows may get terminated, but on
the
decision making functionality other hand other flows will get their QoS restored. Non PCN-
traffic is distributed. These possibilities
are outlined in Section 7.4 and also discussed elsewhere, such as in
[Menth08-3]. treated transparently, ie the PCN-domain is a normal
DiffServ domain.

3.1. Flow admission

The objective of PCN's flow admission and termination decisions need control mechanism is to be enforced
through per flow policing by limit
the PCN-ingress-nodes. If there are
several PCN-domains PCN-traffic on the end-to-end path, then each needs link in the PCN-domain to police
at *roughly* its PCN-ingress-nodes. One exception is if PCN-
admissible-rate, by admitting or blocking prospective new flows, in
order to protect the operator runs both QoS of existing PCN-flows. With three encoding
states available, the access network (not a PCN-domain) and PCN-threshold-rate is configured by the core network (a PCN-
domain); per flow policing could be devolved
operator as equal to the access network
and not done PCN-admissible-rate on each link. It is set
lower than the traffic rate at which the PCN-ingress-node. Note: to aid readability, link becomes congested and
the
rest of this draft assumes that policing is done by node drops packets.

Exactly how the PCN-ingress-
nodes.

PCN admission control has to fit with the overall approach to
admission control. For instance [Briscoe06] decision is made will be defined
separately in informational documents. This document describes two
approaches (others might be possible):

o the case where
RSVP signalling runs end-to-end. PCN-egress-node measures (possibly as a moving average) the
fraction of the PCN-traffic that is threshold-marked. The PCN-domain
fraction is measured for a single RSVP
hop, ie only specific ingress-egress-aggregate. If
the PCN-boundary-nodes process RSVP messages, with RSVP
messages processed on each hop outside fraction is below a threshold value then the PCN-domain, as in IntServ
over DiffServ [RFC2998]. It would also be possible for new flow is
admitted, and if the RSVP
signalling to fraction is above the threshold value then it
is blocked. The fraction could be originated and/or terminated by proxies, with
application-layer signalling between measured as an EWMA
(exponentially weighted moving average), which has sometimes been
called the end user "congestion level estimate".

o the PCN-egress-node monitors PCN-traffic and if it receives one
(or several) threshold-marked packets, then the proxy (eg
SIP signalling with a home hub). A similar example would use NSIS
signalling instead of RSVP.

It new flow is possible that a user wants its inelastic traffic
blocked, otherwise it is admitted. One possibility may be 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 the PCN-domain, so marking state of an initial flow set-up packet (eg
RSVP PATH). Another is that the ECN after one (or several) threshold-
marks then all flows are carried
transparently across blocked until after a specific period of
no congestion.

Note that the PCN-domain, or to use an encoding like
[Moncaster08]. Tunnelling admission control decision is discussed further in Section 7.7.

Some further possible deployment models are outlined in the Appendix. made for a particular

Eardley (Editor) Expires July 18, September 17, 2009 [Page 11] 14]

Internet-Draft PCN Architecture January March 2009

5. Assumptions and constraints on scope

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

The scope objective of PCN's flow termination mechanism is restricted by to limit the following assumptions:

1. these components are deployed
PCN-traffic on each link to *roughly* its PCN-supportable-rate, by
terminating some existing PCN-flows, in a single DiffServ domain, within
which all PCN-nodes are PCN-enabled and are trusted for truthful
PCN-marking and transport

2. all flows handled order to protect the QoS of
the remaining PCN-flows. With three encoding states available, the
PCN-excess-rate is configured by these mechanisms are inelastic and
constrained the operator as equal to a known peak the PCN-
supportable-rate on each link. It may be set lower than the traffic
rate through policing or shaping

3. at which the number of PCN-flows across any potential bottleneck link is
sufficiently large that stateless, statistical mechanisms can becomes congested and the node drops packets.

Exactly how the flow termination decision is made will be
effective. To put it another way, defined
separately in informational documents. This document describes
several approaches (others might be possible):

o In one approach the PCN-egress-node measures the aggregate bit rate of PCN-
traffic across any potential bottleneck link needs to be
sufficiently large relative to the maximum additional bit rate
added by one flow. This that is not excess-traffic-marked, which is the basic assumption amount of measurement-
based admission control.

4. PCN-flows may have different precedence, but
PCN-traffic that can actually be supported, and communicates this
to the applicability of PCN-ingress-node. Also the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.)
is out of scope.

5.1. Assumption 1: Trust and support PCN-ingress-node measures the
rate of PCN - controlled environment

We assume PCN-traffic 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 destined for this assumption:

o specific PCN-egress-
node. The PCN-domain has to difference represents the excess amount that should be encircled by a ring
terminated.

o Another approach instead measures the rate of PCN-boundary-
nodes, otherwise excess-traffic-
marked traffic could enter a PCN-BA without being
subject to admission control, which would potentially degrade the
QoS and terminates this amount of existing PCN-flows.

o Similarly, a PCN-boundary-node has to trust that all the PCN-nodes
mark PCN-traffic consistently. A node not performing PCN-marking
wouldn't be able to 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 traffic. This
terminates less traffic than the Security Considerations
section.

One way previous bullet if some nodes are
dropping PCN-traffic.

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

Since flow termination is designed for "abnormal" circumstances, it
is quite likely that
there some PCN-nodes are several operators congested and hence packets
are being dropped and/or significantly queued. The flow termination
mechanism must accommodate this.

Note also that trust each other in their handling the termination control decision is made for a
particular pair of PCN-traffic.

Note: All PCN-nodes need to be trustworthy. However if PCN-boundary-nodes. So it is known 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.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 12] 15]

Internet-Draft PCN Architecture January March 2009

that an interface cannot become pre-congested then

3.3. Flow admission and/or flow termination when there are only two PCN
encoding states

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

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

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

o both admission control and flow termination: only the excess-
traffic-marking algorithm writes PCN-marks, however the configured
rate (PCN-excess-rate) is set equal to the PCN-admissible-rate, as
shown in Figure 3. [Charny07-2] describes how both admission
control and flow termination can be capable of PCN-marking. But this must be
known even triggered in unusual circumstances, eg after the failure of this case and
also gives some
links.

5.2. Assumption 2: Real-time applications

We assume that any variation of source bit rate is independent of the
level pros and cons of pre-congestion. We assume this approach. The main
downside is that PCN-packets come from real
time applications generating inelastic traffic, ie sending packets at
the rate the codec produces them, regardless admission control is less accurate.

Figure 3: Schematic of
capacity [RFC4594]. For example, voice and video requiring low
delay, jitter and packet loss, how the Controlled Load Service,
[RFC2211], PCN admission control and flow
termination mechanisms operate as the Telephony service class, [RFC4594]. This
assumption is to help focus the effort where it looks like PCN would
be most useful, ie rate of PCN-traffic increases,
for a PCN-domain with two encoding states and using the sorts approach of applications where per flow QoS
[Charny07-2]. Note: U is a
known requirement. In other words we focus on global parameter for all links in the

Eardley (Editor) Expires September 17, 2009 [Page 16]

Internet-Draft PCN providing a
benefit to inelastic traffic (PCN may or may not provide Architecture March 2009

PCN-domain.

3.4. Information transport

The transport of pre-congestion information from a benefit PCN-node to
other types of traffic).

As a consequence, it PCN-
egress-node is assumed that PCN-marking through PCN-markings in data packet headers, ie "in-
band": no signalling protocol messaging is being applied needed. Signalling is
needed to
traffic scheduled with the expedited forwarding per-hop behaviour,
[RFC3246], or a per-hop behaviour with similar characteristics.

5.3. Assumption 3: Many flows and additional load

We assume that there are many PCN-flows on any bottleneck link in the
PCN-domain (or, transport PCN-feedback-information, for example to put it another way, convey
the aggregate bit rate fraction of PCN- PCN-marked traffic across any potential bottleneck link is sufficiently large
relative from a PCN-egress-node to the maximum additional bit rate added
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 one PCN-flow).
Measurement-based admission control assumes that the present is a
reasonable prediction an extension of
RSVP or NSIS, for instance; [Lefaucheur06] describes the future: the network conditions extensions
needed for RSVP.

3.5. PCN-traffic

The following are
measured at the time of a new flow request, however the actual
network performance must some high-level points about how PCN works:

o There needs to be acceptable during a way for a PCN-node to distinguish PCN-traffic
from other traffic. This is through a combination of the call some time
later. One issue DSCP
field and/or ECN field.

o It is not advised to have non PCN-traffic that competes for the
same capacity as PCN-traffic but, if there are only a few variable rate
flows, then the aggregate traffic level may vary a lot, perhaps
enough is such traffic, there
needs to cause some packets be a mechanism to get dropped. If there are many flows
then limit it. "Capacity" means the aggregate traffic level should be statistically smoothed.
How many flows is enough depends
forwarding bandwidth on a number of factors such as the
variation link; "competes" means that non PCN-
packets will delay PCN-packets in each flow's rate, the total rate of PCN-traffic, and the
size of the "safety margin" between queue for the traffic level at which we
start admission-marking and at which packets are dropped or
significantly delayed.

We do not make explicit assumptions on how many PCN-flows are link. Hence
more non PCN-traffic results in each
ingress-egress-aggregate. Performance evaluation work may clarify
whether it is necessary to make any additional assumption on
aggregation at the ingress-egress-aggregate level.

Eardley (Editor) Expires July 18, 2009 [Page 13]

Internet-Draft PCN Architecture January 2009

5.4. Assumption 4: Emergency use out of scope

PCN-flows may have different precedence, but poorer QoS for PCN. Further, the applicability
unpredictable amount of non PCN-traffic makes the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc) is out
of scope of this document.

6. High-level functional architecture

The high-level approach is
less accurate and so reduces PCN's ability to split functionality between:

o PCN-interior-nodes 'inside' protect the PCN-domain, which monitor their
own state QoS of pre-congestion and mark PCN-packets as appropriate.
They are not flow-aware, nor aware
admitted PCN-flows

o Two examples of ingress-egress-aggregates.
The functionality is also done by PCN-ingress-nodes for their
outgoing interfaces such non PCN-traffic (ie those 'inside' that competes for the PCN-domain).

o PCN-boundary-nodes
same capacity as PCN-traffic) are:

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

2. traffic that is scheduled at the edge of same priority as PCN (for
example if the PCN-domain, which control
admission of new PCN-flows Voice-Admit codepoint is used for PCN-traffic
[PCN08-1] and termination of existing PCN-flows,
based on information from PCN-interior-nodes. This information there is non-PCN voice-admit traffic in the form of the PCN-marked data packets (which are intercepted
by the PCN-egress-nodes) and not signalling messages. Generally
PCN-ingress-nodes are flow-aware.

The aim of this split PCN-
domain).

o If there is to keep such non PCN-traffic (ie that competes for the bulk same
capacity as PCN-traffic), then PCN's mechanisms should take
account of the network simple,
scalable and robust, whilst confining policy, application-level and
security interactions it, in order to improve the edge accuracy of the PCN-domain. decision
about whether to admit (or terminate) a PCN-flow. For example the
lack of flow awareness means example,

Eardley (Editor) Expires September 17, 2009 [Page 17]

Internet-Draft PCN Architecture March 2009

one mechanism is that the PCN-interior-nodes don't care
about the flow information associated with PCN-packets, nor do the
PCN-boundary-nodes care about which PCN-interior-nodes its ingress-
egress-aggregates traverse.

In order such non PCN-traffic contributes to generate information about the current state of PCN
meters (ie is metered by the PCN-
domain, each PCN-node PCN-marks packets if threshold-marking and excess-traffic-
marking algorithms).

o There will be non PCN-traffic that doesn't compete for the same
capacity as PCN-traffic, because it is "pre-congested".
Exactly when a PCN-node decides if forwarded at lower
priority. Hence it is "pre-congested" (the
algorithm) and exactly how packets shouldn't contribute to the PCN meters.
Examples are "PCN-marked" (the encoding)
will be defined in separate standards-track documents, but at best effort and assured forwarding traffic. However,
a high
level PCN-node should dedicate some capacity to lower priority traffic
so that it is as follows: isn't starved.

o The document assumes that the algorithms: PCN mechanisms are applied to a PCN-node meters
single behaviour aggregate in the amount of PCN-traffic on
each 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

PCN specifies semantics for the ECN field that differ from the
default semantics of its outgoing (or incoming) links. The measurement is
made as an aggregate [RFC3168]. A particular PCN encoding scheme
needs to describe how it meets the guidelines of all PCN-packets, and not per flow. There
are two algorithms, one BCP 124 [RFC4774]
for threshold-marking and one specifying alternative semantics for excess-
traffic-marking. the ECN field. In summary
the approach is to:

o use a DSCP to allow PCN-nodes to distinguish PCN-traffic that uses
the encoding(s): alternative ECN semantics;

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

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

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

Extended encoding schemes may take different 'appropriate action'.

4. Detailed Functional architecture

This section is set intended to 11 and provide a systematic summary of the DSCP is not new
functional architecture in the PCN-domain. First it describes

Eardley (Editor) Expires July 18, September 17, 2009 [Page 14] 18]

Internet-Draft PCN Architecture January March 2009

altered. Extension encodings may be defined that,

functions needed at most, use a
second DSCP (eg as in [Moncaster08]) and/or set the ECN field to
values other than 11 (eg as three specific types of PCN-node; these are
data plane functions and are in [Menth08-2]).

In a PCN-domain addition to their normal router
functions. Then it describes further functionality needed for both
flow admission control and flow termination; these are signalling and
decision-making functions, and there are various possibilities for
where the operator may have two or three encoding states
available. The baseline encoding provides two encoding states (not
PCN-marked, PCN-marked), whilst extended encodings can provide three
encoding states (not PCN-marked, threshold-marked, excess-traffic-
marked). functions are physically located. The PCN-boundary-nodes monitor the PCN-marked packets 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 order to
extract information about the current state Appendix.

The section then discusses some other detailed topics:

1. addressing

2. tunnelling

3. fault handling

4.1. PCN-interior-node functions

Each link of the PCN-domain. Based
on this monitoring, a distributed decision PCN-domain is made about configured with the following
functionality:

o Behaviour aggregate classification - determine whether to
admit an incoming
packet is a prospective new flow PCN-packet or not.

o Meter - measure the 'amount of PCN-traffic'. The measurement is
made as an aggregate of all PCN-packets, and not per flow.

o PCN-mark - algorithms determine whether to terminate existing
flow(s). Sections 7.4 PCN-mark PCN-packets
and what packet encoding is used.

The functions are defined in [PCN08-2] and 7.5 mention various possibilities for how the functionality could be distributed.

PCN-marking needs baseline encoding in
[PCN08-1] (extended encodings are to be configured on all (potentially pre-congested)
links defined in other documents).

Eardley (Editor) Expires September 17, 2009 [Page 19]

Internet-Draft PCN Architecture March 2009

4.2. PCN-ingress-node functions

Each ingress link of the PCN-domain to ensure that the PCN mechanisms protect all
links. The actual functionality can be is configured on with the outgoing or following
functionality:

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

o Traffic conditioning - or one algorithm police, by 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
configured on the outgoing interface and the other on the incoming
interface. The important point is that
blocked or admitted into a consistent choice is made
across the PCN-domain lower priority behaviour aggregate.)
Similarly, police packets that are part of a previously admitted
flow, to ensure check that the PCN mechanisms protect all
links. See [PCN08-2] flow keeps to the agreed rate or flowspec
(eg [RFC1633] for further discussion.

The objective of a microflow and its NSIS equivalent).

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

o Meter - some approaches to threshold-mark
all PCN-packets whenever flow termination require the PCN-
ingress-node to measure the (aggregate) rate of PCN-packets is greater than some
configured rate, the PCN-threshold-rate. PCN-traffic
towards a particular PCN-egress-node.

The objective of the
excess-traffic-marking algorithm is first two are policing functions, needed to excess-traffic-mark make sure that PCN-
packets at admitted into the PCN-domain belong to a rate equal flow that has been
admitted and to ensure that the difference between flow keeps to the bit flowspec agreed (eg
doesn't exceed an agreed maximum rate of
PCN-packets and some configured rate, the PCN-excess-rate. Note that
this description reflects is inelastic traffic).
Installing the overall intent of filter spec will typically be done by the algorithm rather
than its instantaneous behaviour, since signalling
protocol, as will re-installing the rate measured at filter, for example after a
particular moment depends on re-
route that changes the detailed algorithm, its
implementation, and PCN-ingress-node (see [Briscoe06] for an
example using RSVP). PCN-colouring allows the traffic's variance as well as its rate (eg
marking may well continue after a recent overload even after rest of the
instantaneous rate has dropped). The algorithms are specified in
[PCN08-2].

Admission and termination approaches are detailed and compared in
[Charny07-1] and [Menth08-3]. The discussion below PCN-domain
to recognise PCN-packets.

4.3. PCN-egress-node functions

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

o Packet classify - determine which PCN-ingress-node a brief
summary. It initially assumes there are three encoding states
available. 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.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 15] 20]

Internet-Draft PCN Architecture January March 2009

6.1. Flow admission

The objective metering functionality of PCN's flow course depends on whether it is
targeted at admission control mechanism is to limit or flow termination. Alternatives
involve the PCN-traffic on each link in PCN-egress-node "measuring" as an aggregate (ie not per
flow) all PCN-packets from a particular PCN-ingress-node, or
"monitoring" the PCN-domain PCN-traffic and reacting to *roughly* its one (or several) PCN-
admissible-rate, by admitting or blocking prospective new flows, in
order to protect the QoS of existing PCN-flows. With three encoding
states available,
marked packets. For PCN-colouring, [PCN08-1] specifies that the PCN-threshold-rate is configured by PCN-
egress-node re-sets the
operator as equal ECN field to 00; other encodings may define
different behaviour.

4.4. Admission control functions

As well as 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 functions covered above, other specific admission
control decision is made will functions need to be defined
separately in informational documents. This document describes two
approaches performed (others might be possible):

o Make decision about admission - based on 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 then the new flow is
admitted, and if output of the fraction is above PCN-
egress-node's PCN meter function. In the threshold value then case where it
is blocked. The fraction could be "measures
PCN-traffic", the measured as an EWMA
(exponentially weighted moving average), which has sometimes been
called traffic on the "congestion level estimate".

o ingress-egress-aggregate
is compared with some reference level. In the PCN-egress-node monitors PCN-traffic and if case where it receives one
(or several) threshold-marked packets,
"monitors PCN-marks", then the new flow is
blocked, otherwise it is admitted. One possibility may be to
react to the marking state of an initial flow set-up packet (eg
RSVP PATH). Another decision is that after based on whether one
(or several) threshold-
marks then all flows are blocked until after a specific period packets is (are) PCN-marked or not (eg the RSVP PATH
message). In either case, the admission decision also takes
account of
no congestion.

Note that policy and application layer requirements [RFC2753].

o Communicate decision about admission - signal the decision to the
node making the admission control decision is made request (which may be outside
the PCN-domain), and to the policer (PCN-ingress-node function)
for a particular
pair enforcement of PCN-boundary-nodes. So it is quite possible the decision.

There are various possibilities for a new flow
to how the functionality could be admitted between one pair of PCN-boundary-nodes, whilst at
distributed (we assume the
same time another admission request operator would configure which is blocked between a different
pair of PCN-boundary-nodes.

6.2. Flow termination used):

o The objective of PCN's flow termination mechanism decision is made at the PCN-egress-node and the decision
(admit or block) is signalled to limit the
PCN-traffic on each link to *roughly* its PCN-supportable-rate, PCN-ingress-node.

o The decision is recommended by
terminating some existing PCN-flows, in order to protect the QoS of the remaining PCN-flows. With three encoding states available, PCN-egress-node (admit or
block) but the
PCN-excess-rate decision is configured definitively made by the operator as equal to PCN-ingress-
node. The rationale is that the PCN-
supportable-rate PCN-egress-node naturally has the
necessary information about PCN-marking on each link. It may be set lower than the ingress-egress-
aggregate, but the PCN-ingress-node is the policy enforcement
point [RFC2753], which polices incoming traffic
rate to ensure it is
part of an admitted PCN-flow.

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

Eardley (Editor) Expires July 18, September 17, 2009 [Page 16] 21]

Internet-Draft PCN Architecture January March 2009

Exactly how the flow termination

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

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

4.5. Flow termination functions

As well as the functions covered above, other specific termination
control functions need to be defined
separately in informational documents. This document describes
several approaches performed (others might be possible):

o In one approach the PCN-meter at PCN-egress-node measures - similarly to flow admission, there
are two types of possibilities: to "measure PCN-traffic" on the rate
ingress-egress-aggregate, and 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 that PCN-traffic" being sent towards a particular PCN-egress-node;
again, this is done for the ingress-egress-aggregate and not excess-traffic-marked, which is per
flow.

o (if required) Communicate PCN-feedback-information to the amount of
PCN-traffic node
that can actually be supported, and communicates this makes the flow termination decision. For example, as in
[Briscoe06], communicate the PCN-egress-node's measurements to the
PCN-ingress-node. Also

o Make decision about flow termination - use the PCN-ingress-node measures information from
the
rate PCN-meter(s) to decide which PCN-flow or PCN-flows to
terminate. The decision takes account of PCN-traffic that is destined for this specific PCN-egress-
node, policy and hence it can calculate application
layer requirements [RFC2753].

o Communicate decision about flow termination - signal the excess amount decision
to the node that should is able to terminate the flow (which may be
terminated.

o Another approach instead measures
outside the rate of excess-traffic-
marked traffic PCN-domain), and terminates this amount to the policer (PCN-ingress-node
function) for enforcement of traffic. This
terminates less traffic than the previous bullet if some nodes decision.

There are
dropping PCN-traffic.

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

Since flow termination is designed for "abnormal" circumstances, it
is quite likely that some PCN-nodes are congested and hence packets
are being dropped and/or significantly queued. The flow termination
mechanism must accommodate this.

Note also that discussed above in the termination Admission
control decision is made for a
particular pair section.

4.6. Addressing

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

The PCN-egress-node needs to be terminated between one pair know the address of PCN-boundary-nodes,
whilst at the same time none are terminated between PCN-ingress-node
associated with a different pair
of PCN-boundary-nodes.

6.3. Flow flow, at a minimum so that the PCN-ingress-node can

Eardley (Editor) Expires September 17, 2009 [Page 22]

Internet-Draft PCN Architecture March 2009

be informed to enforce the admission and/or decision (and any flow
termination when there decision) through policing. There are only two PCN
encoding states

If a PCN-domain has only two encoding states available (PCN-marked
and not PCN-marked), various
possibilities for how the PCN-egress-node can do this, ie it associate
the received packet to the correct ingress-egress-aggregate. It is using
not the baseline encoding [PCN08-1],
then an operator has three options (others might be possible): intention of this document to mandate a particular mechanism.

o admission control only: PCN-marking means threshold-marking, ie
only The addressing information can be gathered from signalling. For
example, regular processing of an RSVP PATH message, as the threshold-marking algorithm writes PCN-marks. Only PCN
admission control PCN-
ingress-node is available. the previous RSVP hop (PHOP) ([Lefaucheur06]). Or
the PCN-ingress-node could signal its address to the PCN-egress-
node.

o flow termination only: PCN-marking means excess-traffic-marking,
ie only 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 excess-traffic-marking algorithm writes PCN-marks.
Only PCN termination control data route, interrogating routing
or using a centralised broker).

4.7. Tunnelling

Tunnels may originate and/or terminate within a PCN-domain (eg IP
over IP, IP over MPLS). It is available.

Eardley (Editor) Expires July 18, 2009 [Page 17]

Internet-Draft PCN Architecture January 2009

o both important that the PCN-marking of any
packet can potentially influence PCN's flow admission control and flow termination: only the excess-
traffic-marking algorithm writes PCN-marks, however
termination - it shouldn't matter whether the configured
rate (PCN-excess-rate) is set equal packet happens to be
tunnelled at the PCN-admissible-rate, as
shown 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 Figure 2. [Charny07-2] describes how both admission
control and flow termination can
[RFC2983] should be triggered re-applied in the PCN context. In line with this case
and
also gives some of the pros and cons approach of this approach. The main
downside [RFC4303] and [Briscoe08-2], the following rule
is that admission control applied if encapsulation is less accurate.

Figure 2: Schematic of how done within the PCN-domain:

o any PCN-marking is copied into the outer 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 tunnelling.

Similarly, in line with the PCN admission control and flow
termination mechanisms operate as "uniform conceptual model" of [RFC2983],
the rate "full-functionality option" of PCN-traffic increases,
for a PCN-domain with two encoding states [RFC3168], and using [RFC4301], the approach of
[Charny07-2]. Note: U
following rule is a global parameter for all links in applied if decapsulation is done within the
PCN-domain.

6.4. Information 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 "in-
band": no signalling protocol messaging
domain:

o if the outer header's marking state is needed. Signalling more severe then it is
needed to transport PCN-feedback-information between the PCN-
boundary-nodes, for example to convey
copied onto the fraction of PCN-marked
traffic from a PCN-egress-node to inner header.

Note: 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 order of RSVP or NSIS, for instance;
[Lefaucheur06] describes the extensions needed for RSVP. increasing severity is: not PCN-marked; threshold-

Eardley (Editor) Expires July 18, September 17, 2009 [Page 18] 23]

Internet-Draft PCN Architecture January March 2009

6.5. PCN-traffic

The following are some high-level points about how PCN works:

o There needs to be a way for a PCN-node

marking; excess-traffic-marking.

An operator may wish to distinguish 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 traffic. This is through a combination (PCN and
tunnelling) functions. The potential reasons for doing such
tunnelling are: the PCN-egress-node then automatically knows the
address of the DSCP
field and/or ECN field.

o It is not advised to have non PCN-traffic that competes relevant PCN-ingress-node for the
same capacity as PCN-traffic but, a flow; even if there ECMP is such traffic, there
needs to be a mechanism to limit it. "Capacity" means the
forwarding bandwidth
running, all PCN-packets on a link; "competes" means that non PCN-
packets will delay PCN-packets in particular ingress-egress-aggregate
follow the queue same path. (ECMP: Equal Cost Multi-Path, Section 12.4.)
But it also has drawbacks, for example the link. Hence
more non PCN-traffic results additional overhead in poorer QoS for PCN. Further, the
unpredictable amount
terms of non PCN-traffic makes the PCN mechanisms
less accurate bandwidth and processing, and so reduces PCN's ability to protect the QoS cost of
admitted PCN-flows

o Two examples setting up a mesh
of such non PCN-traffic (ie that competes tunnels between PCN-boundary-nodes (there is an N^2 scaling
issue).

Potential issues arise for the
same capacity as PCN-traffic) are:

1. traffic that a "partially PCN-capable tunnel", ie where
only one tunnel endpoint is priority scheduled over in the PCN (perhaps domain:

1. The tunnel originates outside a particular
application or an operator's control messages).

2. traffic that is scheduled PCN-domain and ends inside it.
If the packet arrives at the tunnel ingress with the same priority
encoding as PCN (for
example if 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
which could potentially confuse nodes beyond the Voice-Admit codepoint is used tunnel egress.

In line with the solution for PCN-traffic
[PCN08-1] and there is non-PCN voice-admit traffic partially capable DiffServ tunnels in
[RFC2983], the PCN-
domain). following rules are applied:

o If there is such non PCN-traffic (ie that competes for For case (1), the same
capacity as PCN-traffic), then PCN's mechanisms should take
account of it, in order to improve tunnel egress node clears any PCN-marking on the accuracy of
inner header. This rule is applied before the decision
about whether to admit (or terminate) a PCN-flow. 'copy on
decapsulation' rule above.

o For example,
one mechanism is that such non PCN-traffic contributes to case (2), the PCN
meters (ie tunnel ingress node clears any PCN-marking on
the inner header. This rule is metered by applied after the threshold-marking and excess-traffic-
marking algorithms).

o There will be non PCN-traffic 'copy on
encapsulation' rule above.

Note that doesn't compete for the same
capacity as PCN-traffic, because it is forwarded at lower
priority. Hence it shouldn't contribute above implies that one has to know, or determine, the PCN meters.
Examples are best effort and assured forwarding traffic. However,
a PCN-node should dedicate some capacity to lower priority traffic
so that it isn't starved.

o The document assumes that
characteristics of the PCN mechanisms are applied to other end of the tunnel as part of
establishing it.

Tunnelling constraints were a
single behaviour aggregate major factor 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. choice of the
baseline encoding. As explained in [PCN08-1], with current
tunnelling endpoints only the 11 codepoint of the ECN field survives

Eardley (Editor) Expires July 18, September 17, 2009 [Page 19] 24]

Internet-Draft PCN Architecture January March 2009

6.6. Backwards compatibility

PCN specifies semantics for

decapsulation, and hence the ECN field that differ from baseline encoding only uses the
default semantics of [RFC3168]. A particular PCN 11
codepoint to indicate PCN-marking. Extended encoding scheme
needs schemes need to describe how it meets the guidelines
explain their interactions with (or assumptions about) tunnelling. A
lengthy discussion of BCP 124 [RFC4774]
for specifying alternative semantics for all the issues associated with layered
encapsulation of congestion notification (for ECN field. In summary
the approach as well as PCN) is to:

o use
in [Briscoe08-2].

4.8. Fault handling

If a DSCP to allow PCN-nodes to distinguish PCN-traffic that uses PCN-interior-node (or one of its links) fails, then lower layer
protection mechanisms or the alternative ECN semantics;

o define these semantics for use within a controlled region, regular IP routing protocol will
eventually re-route around it. If the
PCN-domain;

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

For
admitted traffic, flows will gracefully continue. If instead this
causes early warning of pre-congestion on the baseline encoding [PCN08-1], new route, then
admission control based on pre-congestion notification will ensure
new flows will not be admitted until enough existing flows have
departed. Re-routing may result in heavy (pre-)congestion, when the 'appropriate action'
flow termination mechanism will kick in.

If a PCN-boundary-node fails then we would like the regular QoS
signalling protocol to be responsible for taking appropriate action.
As an example [Briscoe08-2] considers what happens if RSVP is to
block ECN-capable traffic that uses the same DSCP as PCN from
entering QoS
signalling protocol.

5. Operations and Management

This Section considers operations and management issues, under the PCN-domain directly. Blocking means it
FCAPS headings: the Operations and Management of Faults,
Configuration, Accounting, Performance and Security. Provisioning is dropped or
downgraded
discussed with performance.

5.1. Configuration Operations and Management

Threshold-marking and excess-traffic-marking are standardised in
[PCN08-2]. However, more diversity in PCN-boundary-node behaviours
is expected, in order to a lower priority behaviour aggregate, or alternatively
such traffic interface with diverse industry
architectures. It may be tunnelled through possible to have different PCN-boundary-
node behaviours for different ingress-egress-aggregates within the
same PCN-domain. The reason
that 'appropriate action' is needed

A PCN marking behaviour (threshold-marking, excess-traffic-marking)
is that enabled on either the PCN-egress-node
clears egress or the ECN field to 00.

Extended encoding schemes may take different 'appropriate action'.

7. Detailed Functional architecture

This section is intended to provide a systematic summary ingress interfaces of PCN-
nodes. A consistent choice must be made across the new
functional architecture in the PCN-domain. First it describes
functions needed at the three specific types of PCN-node; these are
data plane functions and are in addition PCN-domain to their normal router
functions. Then it describes further functionality needed for both
flow admission control and flow termination; these are signalling and
decision-making functions, and there are various possibilities for
where
ensure that 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 PCN mechanisms protect all links.

PCN configuration control variables fall into the following
categories:

Eardley (Editor) Expires July 18, September 17, 2009 [Page 20] 25]

Internet-Draft PCN Architecture January March 2009

5. other functions needed for flow termination control

Note: Probing

o system options (enabling or disabling behaviours)

o parameters (setting levels, addresses etc)

One possibility is covered in that all configurable variables sit within 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 to be set once to
'globally' control the Appendix.

The section then discusses some other detailed topics:

1. addressing

2. tunnelling

3. fault handling

7.1. PCN-interior-node functions

Each link whole PCN-domain. Where possible, these are
identified below. This may affect operational complexity and the
chances of interoperability problems between equipment from different
vendors.

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

5.1.1. System options

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

o Whether two PCN-markings (threshold-marked and excess-traffic-
marked) are enabled or only one. Typically all nodes throughout a
PCN-domain is will be configured with the following
functionality:

o Behaviour aggregate classification - determine whether same in this respect. However,
exceptions could be made. For example, if most PCN-nodes used
both markings, but some legacy hardware was incapable of running
two algorithms, an incoming
packet is operator might be willing to configure these
legacy nodes solely for excess-traffic-marking to enable flow
termination as a back-stop. It would be sensible to place such
nodes where they could be provisioned with a PCN-packet or not. greater leeway over
expected traffic levels.

o Meter - measure In the 'amount of PCN-traffic'. The measurement case where only one PCN-marking is
made as an aggregate of enabled, all PCN-packets, and not per flow.

o PCN-mark - algorithms determine whether nodes must
be configured to PCN-mark PCN-packets
and what packet encoding is used.

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

7.2. PCN-ingress-node functions

Each ingress link of same meter (ie either
the PCN-domain is configured with threshold meter or the following
functionality: excess traffic meter).

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

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

o Traffic conditioning - police, by dropping or downgrading, flow termination are enabled. If any
packets received with PCN-
interior-node is configured to generate a DSCP indicating PCN transport that do not
belong marking, all PCN-
boundary-nodes must be able to an admitted flow. (A prospective PCN-flow interpret that is
rejected could be blocked or admitted into marking (which
includes understanding, in a lower priority
behaviour aggregate.) Similarly, police packets PCN-domain that are part uses only one type of
a previously admitted flow, to check that the flow keeps to the
agreed rate
PCN-marking, whether they are generated by PCN-interior-nodes'
threshold meters or flowspec (eg [RFC1633] for a microflow and its NSIS
equivalent). the excess traffic meters). Therefore all

Eardley (Editor) Expires July 18, September 17, 2009 [Page 21] 26]

Internet-Draft PCN Architecture January March 2009

o PCN-colour - set the DSCP and ECN fields appropriately for

PCN-boundary-nodes must be configured the
PCN-domain, for example as same in [PCN08-1]. this respect.

o Meter - some approaches to Where flow admission and termination require the decisions are made: at PCN-
ingress-node to measure the (aggregate) rate of PCN-traffic
towards
ingress-nodes or at PCN-egress-nodes (or at a particular PCN-egress-node.

The first two centralised node,
see Appendix B). Theoretically, this configuration choice could
be negotiated for each pair of PCN-boundary-nodes, but we cannot
imagine why such complexity would be required, except perhaps in
future inter-domain scenarios.

o How PCN-markings are policing functions, needed to make sure that PCN-
packets admitted translated into the PCN-domain belong to a flow that has been
admitted admission control and to ensure that the flow keeps to the flowspec agreed (eg
doesn't exceed an agreed maximum rate
termination decisions (see Section 3.1 and is inelastic traffic).
Installing the filter spec Section 3.2).

PCN-egress-nodes will typically have further system options:

o How the mapping should be done established between each packet and its
aggregate, eg by the signalling
protocol, as will re-installing the filter, for example after MPLS label, by IP packet filter spec; and how to
take account of ECMP.

o If an equipment vendor provides a re-
route that changes the PCN-ingress-node (see [Briscoe06] choice, there may be options to
select which smoothing algorithm to use for an
example using RSVP). PCN-colouring allows the rest of the measurements.

5.1.2. Parameters

Like any DiffServ domain, every node within a PCN-domain will need to recognise
be configured with the DSCP(s) used to identify PCN-packets.

7.3. PCN-egress-node functions

Each egress On each
interior link of the PCN-domain is configured with main configuration parameters are the following
functionality:

o Packet classify - determine which PCN-ingress-node PCN-
threshold-rate and PCN-excess-rate. A larger PCN-threshold-rate
enables more PCN-traffic to be admitted on a PCN-packet
has come from.

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

o PCN-colour - for PCN-packets, link, hence improving
capacity utilisation. A PCN-excess-rate set further above the DSCP and ECN fields PCN-
threshold-rate allows greater increases in traffic (whether due to
natural fluctuations or some unexpected event) before any flows are
terminated, ie minimises the
appropriate values for use outside the PCN-domain.

The metering functionality chances of course depends on whether it is
targeted at admission control or flow termination. Alternatives
involve unnecessarily triggering the PCN-egress-node "measuring" as
termination mechanism. For instance, an aggregate (ie not per
flow) all PCN-packets from a particular PCN-ingress-node, or
"monitoring" the PCN-traffic and reacting operator may want to one (or several) PCN-
marked packets. For PCN-colouring, [PCN08-1] specifies design
their network so that the it can cope with a failure of any single PCN-
egress-node re-sets the ECN field
node without terminating any flows.

Setting these rates on first deployment of PCN will be very similar
to 00; other encodings may define
different behaviour.

7.4. Admission 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 traditional process for sizing an admission - based on controlled
network, depending on: the output operator's requirements for minimising
flow blocking (grade of service), the expected PCN traffic load on
each link and its statistical characteristics (the traffic matrix),
contingency for re-routing the PCN-
egress-node's PCN meter function. In traffic matrix in the case where it "measures
PCN-traffic", event of
single or multiple failures, and the measured expected load from other classes
relative to link capacities [Menth07]. But once a domain is in
operation, a PCN design goal is to be able to determine growth in
these configured rates much more simply, by monitoring PCN-marking
rates from actual rather than expected traffic (see Section 5.2 on the ingress-egress-aggregate
is compared with some reference level. In the case where it
Performance & Provisioning).

Eardley (Editor) Expires July 18, September 17, 2009 [Page 22] 27]

Internet-Draft PCN Architecture January March 2009

"monitors PCN-marks", then the decision is based on whether one
(or several) packets is (are) PCN-marked or not (eg the RSVP PATH
message). In either case, the admission decision

Operators may also takes
account of policy and application layer requirements [RFC2753].

o Communicate decision about admission - signal the decision wish to configure a rate greater than the
node making PCN-
excess-rate that is the admission control request (which absolute maximum rate that a link allows for
PCN-traffic. This may simply be outside the PCN-domain), and physical link rate, but some
operators may wish to the policer (PCN-ingress-node function)
for enforcement configure a logical limit to prevent starvation
of other traffic classes during any brief period after PCN-traffic
exceeds the decision.

There are various possibilities for how the functionality could PCN-excess-rate but before flow termination brings it
back below this rate.

Threshold-marking requires a threshold token bucket depth to be
distributed (we assume
configured, excess-traffic-marking needs a value for the operator would configure which is used):

o The decision is made at MTU (maximum
size of a PCN-packet on the PCN-egress-node link) and the decision
(admit or block) is signalled both require setting a maximum
size of their token buckets. It will be preferable for there to the PCN-ingress-node.

o The decision is recommended by the PCN-egress-node (admit or
block) be
rules to set defaults for these parameters, but the decision is definitively made by the PCN-ingress-
node. then allow operators
to change them, for instance if average traffic characteristics
change over time.

The rationale is that the PCN-egress-node naturally has the
necessary information about PCN-marking on the ingress-egress-
aggregate, but the PCN-ingress-node is may allow configuration of the policy enforcement
point [RFC2753], which polices incoming traffic to ensure following:

o how it is
part smooths metering of an admitted PCN-flow. 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 The decision is made at the PCN-ingress-node, which requires an admission control algorithm that is based on 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
marked packets will at least require a centralised node (see Appendix).

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

7.5. Flow termination functions

As well as the functions covered above, other specific marking threshold setting
above which it denies admission to new flows;

o flow termination
control functions need algorithms will probably require a parameter to be performed (others might be possible):
delay termination of any flows until it is more certain that an
anomalous event is not transient;

o PCN-meter at PCN-egress-node - similarly a parameter to flow admission, there control the trade-off between how quickly excess
flows are two types of possibilities: terminated, and over-termination.

One particular approach, [Charny07-2] would require a global
parameter to "measure PCN-traffic" be defined on the
ingress-egress-aggregate, and all PCN-nodes, but only needs one PCN
marking rate to "monitor PCN-marks" be configured on each link. The global parameter is
a scaling factor between admission and react termination (the PCN-traffic
rate on a link up to
one (or several) PCN-marks.

o (if required) PCN-meter at PCN-ingress-node - make "measurements which flows are admitted vs the rate above which
flows are terminated). [Charny07-2] discusses in full the impact of PCN-traffic" being sent towards a particular PCN-egress-node;
again,
this is done for particular approach on the ingress-egress-aggregate operation of PCN.

5.2. Performance & Provisioning Operations and not per
flow. Management

Monitoring of performance factors measurable from *outside* the PCN
domain will be no different with PCN than with any other packet-based

Eardley (Editor) Expires July 18, September 17, 2009 [Page 23] 28]

Internet-Draft PCN Architecture January March 2009

o (if required) Communicate PCN-feedback-information to the node
that makes the

flow termination decision. For example, as in
[Briscoe06], communicate the PCN-egress-node's measurements to admission control system, both at 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 level (blocking
probability, etc) and application
layer requirements [RFC2753].

o Communicate decision about flow termination - signal the decision
to the node packet level (jitter [RFC3393], [Y.1541],
loss rate [RFC4656], mean opinion score [P.800], etc). The
difference is that PCN is able intentionally designed to terminate indicate
*internally* which exact resource(s) are the flow (which may cause of performance
problems and by how much.

Even better, PCN indicates which resources will probably cause
problems if they are not upgraded soon. This can be
outside achieved by the PCN-domain), and to
management system monitoring the policer (PCN-ingress-node
function) for enforcement total amount (in bytes) of PCN-
marking generated by each queue over a period. Given possible long
provisioning lead times, pre-congestion volume is the decision.

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

7.6. Addressing

PCN-nodes may need
reveal whether sufficient persistent demand has occurred to know warrant
an upgrade. Because, even before utilisation becomes problematic,
the address statistical variability of other PCN-nodes. Note: in
all cases PCN-interior-nodes don't need to know the address traffic will cause occasional bursts
of any
other PCN-nodes (except as normal their next hop neighbours, for
routing purposes).

The PCN-egress-node needs to know pre-congestion. This 'early warning system' decouples the address process
of adding customers from the PCN-ingress-node
associated with a flow, at a minimum so that provisioning process. This should cut
the PCN-ingress-node can
be informed time to enforce the add a customer when compared against admission decision (and any flow
termination decision) through policing. There are various
possibilities for how control
provided over native DiffServ [RFC2998], because it saves having to
verify the PCN-egress-node can do this, ie associate capacity planning process before adding each customer.

Alternatively, before triggering an upgrade, the received packet long term pre-
congestion volume on each link can be used to balance traffic load
across the correct ingress-egress-aggregate. It is
not PCN-domain by adjusting the intention link weights of this document the routing
system. When an upgrade to mandate a particular mechanism.

o The addressing information can link's configured PCN-rates is
required, it may also be gathered from signalling. For
example, regular processing of an RSVP Path message, necessary to upgrade the physical capacity
available to other classes. But usually there will be sufficient
physical capacity for the upgrade to go ahead as a simple
configuration change. Alternatively, [Songhurst06] describes an
adaptive rather than preconfigured system, where the configured PCN-
ingress-node
threshold-rate is replaced with a high and low water mark and the previous RSVP hop (PHOP) ([Lefaucheur06]). Or
marking algorithm automatically optimises how physical capacity is
shared using the PCN-ingress-node could signal relative loads from PCN and other traffic classes.

All the above processes require just three extra counters associated
with each PCN queue: threshold-markings, excess-traffic-markings and
drop. Every time a PCN packet is marked or dropped its address size in bytes
should be added to the PCN-egress-
node.

o Always tunnel PCN-traffic across the PCN-domain. appropriate counter. Then the PCN-
ingress-node's address is simply the source address of management
system can read the outer
packet header. The PCN-ingress-node needs counters at any time and subtract a previous
reading to learn establish the address incremental volume of
the PCN-egress-node, either by manual configuration or by one each type of
the automated tunnel endpoint discovery mechanisms (such as
signalling or probing over the data route, interrogating routing
or using a centralised broker).
(pre-)congestion. Readings should be taken frequently, so that
anomalous events (eg re-routes) can be distinguished from regular
fluctuating demand if required.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 24] 29]

Internet-Draft PCN Architecture January March 2009

7.7. Tunnelling

Tunnels may originate and/or terminate within a PCN-domain (eg IP
over IP, IP over MPLS). It is important that the PCN-marking of any
packet can potentially influence PCN's flow admission control

5.3. Accounting Operations and
termination - Management

Accounting is only done at trust boundaries so it shouldn't matter whether the packet happens is out of scope of
this document, which is confined to intra-domain issues. Use of PCN
internal 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 domain makes no difference to the "uniform conceptual model" described in
[RFC2983] should be re-applied in flow signalling
events crossing trust boundaries outside the PCN context. In line with this PCN-domain, which are
typically used for accounting.

5.4. Fault Operations and the approach of [RFC4303] Management

Fault Operations and [Briscoe08-2], the following rule
is applied if encapsulation is done within the PCN-domain:

o any PCN-marking Management is copied into the outer 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 tunnelling.

Similarly, in line with about preventing faults, telling
the "uniform conceptual model" of [RFC2983], management system (or manual operator) that the "full-functionality option" of [RFC3168], system has
recovered (or not) from a failure, and [RFC4301], the
following rule is applied if decapsulation is done within the PCN-
domain:

o 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 the outer header's marking state is more severe then they
didn't work after an option had been accidentally disabled.
Therefore it will be necessary to regularly test that the live system
works as intended (devising a meaningful test is
copied onto left as an exercise
for the inner header.

Note: operator).

Section 4 describes how the order of increasing severity is: not PCN-marked; threshold-
marking; excess-traffic-marking.

An operator may wish PCN architecture has been designed to tunnel PCN-traffic
ensure admitted flows continue gracefully after recovering
automatically from PCN-ingress-nodes to
PCN-egress-nodes. link or node failures. The PCN-marks shouldn't be visible outside the
PCN-domain, which can be achieved need to record and
monitor re-routing events affecting signalling is unchanged by the PCN-egress-node doing the
PCN-colouring function (Section 7.3) after all
addition of PCN to a DiffServ domain. Similarly, re-routing events
within the other (PCN PCN-domain will be recorded and
tunnelling) functions. The potential reasons for doing such
tunnelling are: monitored just as they
would be without PCN.

PCN-marking does make it possible to record 'near-misses'. For
instance, at the PCN-egress-node then automatically knows a 'reporting threshold' could be set
to monitor how often - and for how long - the
address system comes close to
triggering flow blocking without actually doing so. Similarly,
bursts of flow termination marking could be recorded even if they are
not sufficiently sustained to trigger flow termination. Such
statistics could be correlated with per-queue counts of marking
volume (Section 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 relevant PCN-ingress-node for
management process ('human error'): a flow; even if ECMP is
running, all PCN-packets on wrongly configured address in a particular ingress-egress-aggregate
follow the same path. But it also has drawbacks, for example the
additional overhead
node, a wrong address given in terms of bandwidth and processing, and the
cost of setting up a mesh of tunnels between PCN-boundary-nodes
(there is an N^2 scaling issue).

Potential issues arise for signalling protocol, a "partially PCN-capable tunnel", ie where
only one tunnel endpoint is wrongly
configured parameter in the PCN domain: 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

Eardley (Editor) Expires July 18, September 17, 2009 [Page 25] 30]

Internet-Draft PCN Architecture January March 2009

1. The tunnel originates outside a PCN-domain and ends inside it.
If the packet arrives

practice at the tunnel ingress with the same
encoding as 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 PCN-domain 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 indicate PCN-marking,
then this could lead the PCN-egress-node to falsely measure pre-
congestion.

2. general good
practice required in this field [RFC4778], other than those below.
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
which could potentially confuse nodes beyond the tunnel egress.

In line with correct functions of the solution for partially capable DiffServ tunnels system should be monitored (Section 5.2)
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 multiple independent ways and correlated to detect possible
security breaches. Persistent (pre-)congestion marking should raise
an alarm (both on
decapsulation' rule above.

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

Note that the above implies that one has to know, PCN-egress-
node metering it). Similarly, persistently poor external QoS metrics
(such as jitter or determine, the
characteristics of the other end mean opinion score) should raise an alarm. The
following are examples of symptoms that may be the tunnel as part result of
establishing it.

Tunnelling constraints were innocent
faults, rather than attacks, but until diagnosed they should be
logged and trigger a major factor in the choice of the
baseline encoding. As explained in [PCN08-1], with current
tunnelling endpoints only the 11 codepoint security alarm:

o Anomalous patterns of the ECN field survives
decapsulation, non-conforming incoming signals and hence the baseline encoding only uses packets
rejected at the 11
codepoint to indicate PCN-marking. Extended encoding schemes need to
explain their interactions 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 (or assumptions about) tunnelling. no
associated state for mapping them to a valid ingress-egress-
aggregate.

o A
lengthy discussion of all PCN-ingress-node receiving feedback signals about the issues associated with layered
encapsulation of pre-
congestion notification (for ECN as well as PCN) is
in [Briscoe08-2].

7.8. Fault handling

If level on a PCN-interior-node (or one of its links) fails, then lower layer
protection mechanisms non-existent aggregate, 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 that are
inconsistent with other signals (eg unexpected sequence numbers,
inconsistent addressing, conflicting reports of pre-congestion on the new route, then
admission control based on pre-congestion notification will ensure
new flows will not be admitted until enough existing flows have
departed. Re-routing may result in heavy (pre-)congestion, when the
flow termination mechanism will kick in.

Eardley (Editor) Expires July 18, 2009 [Page 26]

Internet-Draft PCN Architecture January 2009

If
level, etc).

o Pre-congestion marking arriving at a PCN-boundary-node fails then we would like PCN-egress-node with
(pre-)congestion markings focused on particular flows, rather than
randomly distributed throughout the regular QoS
signalling protocol aggregate.

6. IANA Considerations

This memo includes no request to be responsible for taking appropriate action.
As an example [Briscoe08-2] considers what happens if RSVP is IANA.

Eardley (Editor) Expires September 17, 2009 [Page 31]

Internet-Draft PCN Architecture March 2009

7. Security considerations

Security considerations essentially come from the QoS
signalling protocol.

8. Challenges

Prior work on Trust Assumption
(Section 12.3.1), ie that all PCN-nodes are PCN-enabled and are
trusted for truthful PCN-marking and transport. PCN splits
functionality between PCN-interior-nodes and similar mechanisms has thrown up a number of PCN-boundary-nodes, and
the security considerations about PCN's design goals (things PCN should be good
at) are somewhat different for each, mainly
because PCN-boundary-nodes are flow-aware and some issues PCN-interior-nodes are
not.

o Because the PCN-boundary-nodes are flow-aware, they are trusted to
use that awareness correctly. The degree of trust required
depends on the kinds of decisions they have been hard to solve in a fully
satisfactory manner. Taken as a whole it represents a list make and the kinds
of trade-
offs (it is unlikely that information they can all be 100% achieved) and perhaps
as evaluation criteria need to help an operator (or the IETF) decide
between options.

The following are open issues. They are mainly taken from
[Briscoe06], which also describes some possible solutions. Note that
some may be considered unimportant in general or in make them. There is nothing specific
deployment scenarios or by some operators.

NOTE: Potential solutions are out of scope for this document.
to PCN.

o ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion PCN-ingress-nodes police packets to ensure a PCN-flow sticks
within its agreed limit, and 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. This is measured on a specific ingress-egress-aggregate. However, if
similar to the PCN-domain runs ECMP, then traffic on this ingress-egress-
aggregate may follow several different paths - some of existing IntServ behaviour. Between them the paths PCN-
boundary-nodes must encircle the PCN-domain, otherwise PCN-packets
could be pre-congested whilst others are not. There enter the PCN-domain without being subject to admission
control, which would potentially destroy the QoS of existing
flows.

o PCN-interior-nodes are three
potential problems:

1. over-admission: a new flow is admitted (because not flow-aware. This prevents some
security attacks where an attacker targets specific flows in the pre-
congestion level measured
data plane - for instance for DoS or eavesdropping.

o The PCN-boundary-nodes rely on correct PCN-marking by the PCN-egress-node is
sufficiently diluted by unmarked PCN-
interior-nodes. For instance a rogue PCN-interior-node could PCN-
mark all packets from non-congested
paths so that a new flow no flows were admitted. Another
possibility is admitted), but its packets travel
through a pre-congested PCN-node.

2. under-admission: a new flow that it doesn't PCN-mark any packets, even when it
is blocked (because pre-congested. More subtly, the pre-
congestion level measured by rogue PCN-interior-node could
perform these attacks selectively on particular flows, or it could
PCN-mark the PCN-egress-node is
sufficiently increased by PCN-marked packets correct fraction overall, but carefully choose which
flows 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 must be protected
from pre-
congested paths attacks. For example the recipient needs to validate that 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
the (pre-)congested router(s). Since
flow termination message is a 'last resort', which protects indeed from the
network should over-admission occur, this problem is probably
more important node that claims to solve than the other two. have sent it.
Possible measures include digest authentication and protection

Eardley (Editor) Expires July 18, September 17, 2009 [Page 27] 32]

Internet-Draft PCN Architecture January March 2009

o ECMP

against replay and signalling: It man-in-the-middle attacks. For the specific
protocol RSVP, hop-by-hop authentication is possible that, in [RFC2747], and
[Behringer07] may also be useful.

Operational security advice is given in Section 5.5.

8. Conclusions

The document describes a PCN-domain running
ECMP, general architecture for flow admission and
termination based on pre-congestion information in order to protect
the signalling packets (eg RSVP, NSIS) follow quality of service of established inelastic flows within a different
path than single
DiffServ domain. The main topic is the data packets, which could matter if functional architecture. It
also mentions other topics like the signalling
packets are used as probes. Whether this assumptions and open issues.

9. Acknowledgements

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

Thanks to those who have made comments on
which fields the ECMP algorithm uses; if the ECMP algorithm is
restricted 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, Ruediger Geib, Wei Gengyu, Robert
Hancock, Fortune Huang, Christian Hublet, Cullen Jennings, Ingemar
Johansson, Georgios Karagiannis, Hein Mekkes, Michael Menth, Toby
Moncaster, Dan Romascanu, Daisuke Satoh, Ben Strulo, Tom Taylor,
Hannes Tschofenig, Tina Tsou, David Ward, Lars Westberg, Magnus
Westerlund, Delei Yu. Thanks to Bob Briscoe who extensively revised
the source and destination IP addresses, then it
will not be an issue. ECMP Operations and signalling interactions are a
specific instance 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 to determine Management section.

This document is the path result of discussions in the PCN-domain. The problem,
its impact, PCN WG and
forerunner activity in the potential solutions TSVWG. A number of previous drafts were
presented to TSVWG; their authors were: B, Briscoe, P. Eardley, D.
Songhurst, F. Le Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley,
G. Karagiannis, A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G.
Liu, A. Bhargava.

10. Comments Solicited

Comments and questions are similar encouraged and very welcome. They can be
addressed to those for
ECMP.

o Scenarios with only one tunnel endpoint in the IETF PCN domain may make
it harder for the PCN-egress-node to gather working group mailing list <pcn@ietf.org>.

Eardley (Editor) Expires September 17, 2009 [Page 33]

Internet-Draft PCN Architecture March 2009

11. Changes

11.1. Changes from the signalling
messages (eg RSVP, NSIS) the identity of the PCN-ingress-node.

o Bi-Directional Sessions: Many applications have bi-directional
sessions - hence there are two microflows that should be admitted
(or terminated) as a pair - -098 to -10

Changes to deal with IESG comments:

o New introduction to provide gentler introduction for instance a bi-directional voice
call only makes sense if microflows in both directions are
admitted. However, the PCN mechanisms concern admission and
termination
novice: quick summary of a single flow, PCN's applicability; quick example of how
it all hangs together in one end-to-end qos scenario; quick
summary of PCN "documentation"

o OAM changed to Operations and coordination Management

o Processed some of the decision for
both flows is a matter for minor suggestions in the signalling protocol and out of
scope of PCN. One possible example would use SIP pre-conditions.
However, there are others. Gen-ART Review by
Francis Dupont

o Global Coordination: PCN makes its admission decision based on
PCN-markings Two wording tweaks in Sections 3.2 & 3.4 (as agreed 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, mailing
list)

o Updated boilerplate. this draft may include material pre- Nov 10
2008 blah.

11.2. Changes from a global perspective, it would be
better -08 to -09

Small changes to deal with WG Chair comments:

o tweak language in various places to make it more RFC-like and less
that of a coordinated decision across all the ingress-
egress-aggregates scholarly work, for the whole PCN-domain. For example, instance from "we propose" to 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. "this
document describes"

o Aggregate Traffic Characteristics: Even when the number of flows
is stable, the traffic level through the PCN-domain will vary
because the sources vary their traffic rates. PCN works best when
there is not too much variability tweak language in various places to make it a stand alone
architecture document rather than a discussion of the total traffic level PCN WG. Now
only mentions WG at a
PCN-node's interface (ie in start of Annex.

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

o References: removed some of less important references to IDs

11.3. Changes from all
sources). Too much variation means that a node may (at one
moment) not be doing any PCN-marking -07 to -08

Small changes from second WG last call:

o Section 2: added definition for PCN-admissible-rate and then (at another moment) 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 to Figs 1 & 2.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 28] 34]

Internet-Draft PCN Architecture January March 2009

drop packets because it is overloaded. This makes it hard to tune
the admission control scheme to stop admitting new flows at

o added the
right time. Therefore phrase "(others might be possible") before the problem is more likely with fewer,
burstier flows.

o Flash crowds and Speed of Reaction: PCN is a 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, potentially if a big burst list of
approaches in Section 6.3, 7.4 & 7.5.

o added references to RFC2753 (A framework for policy-based
admission requests occurs control) in a very short space of time (eg
prompted by a televote), they could all get admitted before enough
PCN-marks S7.4 & S7.5.

o throughout, updated references now that marking behaviour &
baseline encoding are seen WG drafts.

o a few typos corrected

11.4. Changes from -06 to block new flows. In -07

References re-formatted to pass ID nits. No other words, any
additional load offered within the reaction time of the mechanism
must not move the PCN-domain directly changes.

11.5. Changes from a no congestion state -05 to overload. This 'vulnerability period' may have an impact at -06

Minor clarifications throughout, the signalling level, for instance QoS requests should be rate
limited least insignificant are as
follows:

o Section 1: added to bound the number list of requests able to arrive within the
vulnerability period. encoding states in an 'extended'
scheme: "or perhaps further encoding states as suggested in
draft-westberg-pcn-load-control"

o Silent at start: after a successful admission request the source
may wait some time before sending data (eg waiting Section 2: added definition for PCN-colouring (to clarify that the called
party to answer). Then the risk
term is that, in some circumstances,
PCN's measurements underestimate what the pre-congestion level
will be when the source does start sending data.

9. Operations and Management

This used consistently differently from 'PCN-marking')

o Section considers operations 6.1 and management issues, under 6.2: added "(others might be possible)" before the
FCAPS headings: OAM
list of Faults, Configuration, Accounting, Performance
and Security. Provisioning is discussed with performance.

9.1. Configuration OAM

Threshold-marking and excess-traffic-marking are standardised in
[PCN08-2]. However, more diversity high level approaches for making flow admission
(termination) decisions.

o Section 6.2: corrected a significant typo in PCN-boundary-node behaviours
is expected, 2nd bullet (more ->
less)

o Section 6.3: corrected a couple of significant typos in order Figure 2

o Section 6.5 (PCN-traffic) re-written for clarity. Non PCN-traffic
contributing to interface with diverse industry
architectures. It PCN meters is now given as an example (there may
be possible cases where don't need to have different PCN-boundary-
node behaviours for different ingress-egress-aggregates meter it).

o Section 7.7: added to the text about encapsulation being done
within the
same PCN-domain. PCN-domain: "Note: A PCN marking tunnel will not provide this
behaviour (threshold-marking, excess-traffic-marking)
is enabled on if it complies with [RFC3168] tunnelling in either the egress or the ingress interfaces mode,
but it will if it complies with [RFC4301] IPSec tunnelling."

o Section 7.7: added mention of PCN-
nodes. A consistent choice must be made across the PCN-domain [RFC4301] to
ensure that the PCN mechanisms protect all links.

PCN configuration control variables fall into text about
decapsulation being done within the following
categories: PCN-domain.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 29] 35]

Internet-Draft PCN Architecture January March 2009

o system options (enabling or disabling behaviours) Section 8: deleted the text about design goals, since this is
already covered adequately earlier eg in S3.

o parameters (setting levels, addresses etc)

One Section 11: replaced the last sentence of bullet 1 by "There is
nothing specific to PCN."

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

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

11.6. Changes from -04 to -05

Minor nits removed as follows:

o Further minor changes to reflect that baseline encoding 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 in S7.1) and that it is not advised to have non
PCN-traffic that all configurable variables sit within an SNMP
management framework [RFC3411], being structured within shares the same capacity (on a defined
management information base (MIB) link) as PCN-
traffic (so added bullet in S6.5)

o Probing moved into Appendix A and deleted the 'third viewpoint'
(admission control based on each node, the marking of a single packet like an
RSVP PATH message) - since this isn't really probing, and being remotely
readable in any
case is already mentioned in S6.1.

o Minor changes to S9 Operations and settable via a suitably secure management protocol
(SNMPv3).

Some configuration options and - mainly to reflect
that consensus on marking behaviour has simplified things so eg
there are fewer parameters have to be set once configure.

o A few terminology-related errors expunged, and two pictures added
to
'globally' control help.

o Re-phrased the whole PCN-domain. Where possible, these are
identified below. This may affect operational complexity and claim about the
chances of interoperability problems between equipment from different
vendors.

It may be possible for an operator to configure some PCN-interior-
nodes so natural decision point in S7.4

o Clarified that extended encoding schemes need to explain their
interactions with (or assumptions about) tunnelling (S7.7) and how
they don't run meet the PCN mechanisms, if it knows that
these links will never become (pre-)congested.

9.1.1. System options

On PCN-interior-nodes there will be very few system options: guidelines of BCP124 (S6.6)

o Whether two PCN-markings (threshold-marked and excess-traffic-
marked) are enabled or only one. Typically all nodes Corrected the third bullet in S6.2 (to reflect consensus about
PCN-marking)

Eardley (Editor) Expires September 17, 2009 [Page 36]

Internet-Draft PCN Architecture March 2009

11.7. Changes from -03 to -04

o Minor changes throughout a
PCN-domain will be configured to reflect the same consensus call about PCN-
marking (as reflected in this respect. However,
exceptions 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 [PCN08-2]).

o Minor changes throughout to configure these
legacy nodes solely for excess-traffic-marking reflect the current decisions about
encoding (as reflected in [PCN08-1] and [Moncaster08]).

o Introduction: re-structured to enable flow
termination as a back-stop. It would be sensible create new sections on Benefits,
Deployment scenarios and Assumptions.

o Introduction: Added pointers to place such
nodes where they could be provisioned with a greater leeway over
expected traffic levels. other PCN documents.

o In the case where only one PCN-marking is enabled, all nodes must
be configured Terminology: changed PCN-lower-rate to generate PCN-marks PCN-threshold-rate and PCN-
upper-rate to PCN-excess-rate; excess-rate-marking to excess-
traffic-marking.

o Benefits: added bullet about SRLGs.

o Deployment scenarios: new section combining material from various
places within the same meter (ie either
the threshold meter or document.

o S6 (high level functional architecture): re-structured and edited
to improve clarity, and reflect the excess traffic meter).

PCN-boundary-nodes (ingress latest PCN-marking and egress) will have more system
options:
encoding drafts.

o Which of S6.4: added claim that the most natural place to make an admission and flow termination are enabled. If any PCN-
interior-node
decision is configured to generate a marking, all PCN-
boundary-nodes must be able to interpret that marking (which
includes understanding, in a PCN-domain PCN-egress-node.

o S6.5: updated the bullet about non-PCN-traffic that uses only one type of
PCN-marking, whether they are generated 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.

11.8. Changes from -02 to -03

o Abstract: Clarified by PCN-interior-nodes'
threshold meters or removing the excess traffic meters). Therefore all term 'aggregated'. Follow-up
clarifications later in draft: S1: expanded PCN-egress-nodes
bullet to mention case where the PCN-feedback-information is about
one (or a few) PCN-marks, rather than aggregated information; S3
clarified PCN-meter; S5 minor changes; conclusion.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 30] 37]

Internet-Draft PCN Architecture January March 2009

PCN-boundary-nodes must be configured the same in this respect.

o Where flow admission and termination decisions are made: at PCN-
ingress-nodes or at PCN-egress-nodes (or at S1: added a centralised node,
see Appendix). Theoretically, this configuration choice could be
negotiated for each pair of PCN-boundary-nodes, but we cannot
imagine why such complexity would be required, except perhaps in
future inter-domain scenarios.

o How PCN-markings are translated into admission control and flow
termination decisions (see Section 6.1 and Section 6.2).

PCN-egress-nodes will have further system options:

o How the mapping should be established between each packet and its
aggregate, eg by MPLS label, by IP packet filterspec; and paragraph about how the PCN-domain looks to
take account of ECMP.

o If an equipment vendor provides a choice, there may be options to
select which smoothing algorithm to use for measurements.

9.1.2. Parameters

Like any DiffServ domain, every node within the
outside world (essentially it looks like a PCN-domain will need DiffServ domain).

o S2: tweaked the PCN-traffic terminology bullet: changed PCN
traffic classes to PCN behaviour aggregates, to be configured more in line
with the DSCP(s) used traditional DiffServ jargon (-> follow-up changes later in
draft); included a definition of PCN-flows (and corrected a couple
of 'PCN microflows' to identify PCN-packets. On each
interior link the main configuration parameters are the 'PCN-flows' later in draft)

o S3.5: added possibility of downgrading to best effort, where PCN-
threshold-rate and PCN-excess-rate. A larger PCN-threshold-rate
enables more PCN-traffic
packets arrive at PCN-ingress-node already ECN marked (CE or ECN
nonce)

o S4: added note about whether talk about PCN operating on an
interface or on a link. In S8.1 (OAM) mentioned that PCN
functionality needs to be admitted configured consistently on a link, hence improving
capacity utilisation. A PCN-excess-rate set further above either the PCN-
threshold-rate allows greater increases in traffic (whether due to
natural fluctuations
ingress or some unexpected event) before any flows are
terminated, ie minimises the chances egress interface of unnecessarily triggering the
termination mechanism. For instance, an operator may want to design
their network so PCN-nodes in a PCN-domain.

o S5.2: clarified that it can cope with 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 of N^2 scaling if you set up a failure mesh
of any single PCN-
node without terminating any flows.

Setting these rates on first deployment tunnels between PCN-boundary-nodes

o S7.3: Clarified the "third viewpoint" of probing (always probe).

o S8.1: clarified that SNMP is only an example; added note that an
operator may be able to not run PCN on some PCN-interior-nodes, if
it knows that these links will never become (pre-)congested; added
note that it may be very similar possible to the traditional process have different PCN-boundary-node
behaviours for sizing different ingress-egress-aggregates within the same
PCN-domain.

o Appendix: Created an admission controlled
network, depending on: Appendix about "Possible work items beyond
the operator's requirements for minimising
flow blocking (grade scope of service), the expected PCN traffic load on
each link and its statistical characteristics (the traffic matrix),
contingency for re-routing the current PCN traffic matrix in the event WG Charter". Material moved from
near start of
single or multiple failures, S3 and the expected load from other classes
relative elsewhere throughout draft. Moved text about
centralised decision node to link capacities [Menth07]. But once a domain is in
operation, a PCN design goal is Appendix.

o Other minor clarifications.

11.9. Changes from -01 to be able -02

o S1: Benefits: provisioning bullet extended to determine growth in
these configured rates much more simply, by monitoring PCN-marking
rates from actual rather than expected stress that PCN does
not use RFC2475-style traffic (see Section 9.2 on
Performance & Provisioning). conditioning.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 31] 38]

Internet-Draft PCN Architecture January March 2009

Operators may also wish

o S1: Deployment models: mentioned, as variant of PCN-domain
extending to configure a rate greater than the PCN-
excess-rate end nodes, that is the absolute maximum rate may extend to LAN edge switch.

o S3.1: Trust Assumption: added note about not needing PCN-marking
capability if known that a link allows an interface cannot become pre-congested.

o S4: now divided into sub-sections

o S4.1: Admission control: added second proposed method for
PCN-traffic. This may simply be the physical link rate, but some
operators may wish how to configure a logical limit
decide to prevent starvation block new flows (PCN-egress-node receives one (or
several) PCN-marked packets).

o S5: Probing sub-section removed. Material now in new S7.

o S5.6: Addressing: clarified how PCN-ingress-node can discover
address of other traffic classes during any brief period after PCN-traffic
exceeds the PCN-excess-rate but before flow termination brings it
back below this rate.

Threshold-marking requires a threshold token bucket depth PCN-egress-node

o S5.6: Addressing: centralised node case, added that PCN-ingress-
node may need to be
configured, excess-traffic-marking needs a value for the MTU (maximum
size know address of a PCN-packet PCN-egress-node

o S5.8: Tunnelling: added case of "partially PCN-capable tunnel" and
degraded bullet on the link) this in S6 (Open Issues)

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

o S8: Operations and both require setting a maximum
size of their token buckets. It will be preferable for there Management: substantially revised.

o other minor changes not affecting semantics

11.10. Changes from -00 to be
rules -01

In addition to set defaults for these parameters, but then allow operators clarifications and nit squashing, the main changes
are:

o S1: Benefits: added one about provisioning (and contrast with
DiffServ SLAs)

o S1: Benefits: clarified that the objective is also to change them, for instance if average traffic characteristics
change over time.

The PCN-egress-node may allow configuration stop PCN-
packets being significantly delayed (previously only mentioned not
dropping packets)

o S1: Deployment models: added one where policing is done at ingress
of access network and not at ingress of the following: PCN-domain (assume trust
between networks)

o how it smooths metering S1: Deployment models: corrected MPLS-TE to MPLS

Eardley (Editor) Expires September 17, 2009 [Page 39]

Internet-Draft PCN Architecture March 2009

o S2: Terminology: adjusted definition of PCN-markings (eg EWMA parameters)

Whichever node makes admission PCN-domain

o S3.5: Other assumptions: corrected, so that two assumptions (PCN-
nodes not performing ECN and flow termination decisions will
contain algorithms for converting PCN-ingress-node discarding arriving
CE packet) only apply if the PCN WG decides to encode PCN-marking levels into admission
or flow termination decisions. These will also require configurable
parameters, for instance:
in the ECN-field.

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

o S4: clarified that PCN-interior-node functionality applies for
each outgoing interface, and added clarification: "The
functionality is based on also done by PCN-ingress-nodes for their outgoing
interfaces (ie those 'inside' the fraction of
marked packets will at least require a marking threshold setting
above which it denies admission to new flows; PCN-domain)."

o flow termination algorithms will probably require S4 (near end): altered to say that a parameter PCN-node "should" dedicate
some capacity to
delay termination of any flows until lower priority traffic so that it is more certain isn't starved
(was "may")

o S5: clarified to say that PCN functionality is done on an
anomalous event
'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 of probing; added that in the case
where traffic is not transient;

o always tunnelled across the PCN-domain, add a parameter
note that he PCN-ingress-node needs to control know the trade-off between how quickly excess
flows are terminated, and over-termination.

One particular approach, [Charny07-2] would require a global
parameter address of the
PCN-egress-node.

o S5.8: Tunnelling: re-written, especially to be defined provide a clearer
description of copying on all PCN-nodes, but only needs tunnel entry/exit, by adding explanation
(keeping tunnel encaps/decaps and PCN-marking orthogonal),
deleting one PCN bullet ("if the inner header's marking rate to be configured on each link. The global parameter state is
a scaling factor between admission more
sever then it is preserved" - shouldn't happen), and termination (the PCN-traffic
rate on a link up to which flows are admitted vs the rate above which
flows better
referencing of other IETF documents.

o S6: Open issues: stressed that "NOTE: Potential solutions are terminated). [Charny07-2] discusses in full the impact out
of scope for this particular approach on the operation of PCN.

9.2. Performance & Provisioning OAM

Monitoring document" and edited a couple of performance factors measurable from *outside* sentences that
were close to solution space.

o S6: Open issues: added one about scenarios with only one tunnel
endpoint in the PCN domain will be no different with PCN than with any other packet-based .

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

Eardley (Editor) Expires July 18, September 17, 2009 [Page 32] 40]

Internet-Draft PCN Architecture January March 2009

flow admission control system, both at the 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

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

o S10: Conclusions: a small conclusions section added

12. Appendix A: Applicability of PCN is intentionally designed to indicate
*internally* which exact resource(s) are

12.1. Benefits

We believe that the cause key benefits of performance
problems and by how much.

Even better, the PCN indicates which resources will probably cause
problems if mechanisms described in
this document are that they are not upgraded soon. This can be achieved by the
management system monitoring the total amount (in bytes) of PCN-
marking generated by each queue over a period. Given possible long
provisioning lead times, pre-congestion volume simple, scalable, and robust because:

o Per flow state is only required at the best metric to
reveal whether sufficient persistent demand has occurred to warrant
an upgrade. Because, even before utilisation becomes problematic,
the statistical variability of traffic will cause occasional bursts
of pre-congestion. PCN-ingress-nodes
("stateless core"). This 'early warning system' decouples the process
of adding customers is required for policing purposes (to
prevent non-admitted PCN traffic from entering the provisioning process. This should cut
the time to add a customer when compared against admission 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
provided over native DiffServ [RFC2998], because it saves having to
verify the capacity planning process before adding each customer.

Alternatively, before triggering an upgrade, is resilient: with PCN QoS is decoupled from the long term pre-
congestion volume
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 used 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 balance link failures
are more likely than QoS violations due to increased traffic load
across
volume [Iyer03].

o The PCN-marking behaviours only operate on the PCN-domain by adjusting overall PCN-traffic
on the link weights link, not per flow.

o The information of the routing
system. When an upgrade to a link's configured PCN-rates these measurements is
required, it may also be necessary signalled to upgrade the physical capacity
available to other classes. But usually there will be sufficient
physical capacity for PCN-
egress-nodes by the upgrade to go ahead as a simple
configuration change. Alternatively, [Songhurst06] describes an
adaptive rather than preconfigured system, where PCN-marks in the configured PCN-
threshold-rate packet headers, ie [Style]
"in-band". No additional signalling protocol is replaced with a high and low water mark and required for
transporting the
marking algorithm automatically optimises how physical capacity PCN-marks. Therefore no secure binding is
shared using the relative loads from PCN
required between data packets and other traffic classes.

All separate congestion messages.

o The PCN-egress-nodes make separate measurements, operating on the above processes require just three extra counters associated
with
aggregate PCN-traffic from each PCN queue: threshold-markings, excess-traffic-markings 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
drop. Every time a PCN packet termination
decisions) is marked or dropped its size in bytes
should be added to at the appropriate counter. Then granularity of the management
system can read ingress-egress-aggregate.
An alternative approach is that the counters at any time PCN-egress-nodes monitor the
PCN-traffic and subtract a previous
reading to establish signal PCN-feedback-information (which is used for
flow admission and termination decisions) at the incremental volume of each type granularity of
(pre-)congestion. Readings should be taken frequently, so that
anomalous events (eg re-routes) can be distinguished from regular
fluctuating demand if required.
one (or a few) PCN-marks.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 33] 41]

Internet-Draft PCN Architecture January March 2009

9.3. Accounting OAM

Accounting

o The admitted PCN-load is only done at trust boundaries so controlled dynamically. Therefore 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.

9.4. Fault OAM

Fault OAM is about preventing faults, telling the management system
(or manual operator) that
adapts as the system has recovered (or not) from a
failure, and about maintaining information to aid fault diagnosis.

Admission blocking traffic matrix changes, and particularly flow termination mechanisms
should rarely be needed in practice. It would be unfortunate also if they
didn't work the network
topology changes (eg after a link failure). Hence an option had been accidentally disabled.
Therefore it will operator can
be necessary 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 regularly test 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 live system
works as intended (devising
measurement-based admission control in the presence of admitted
flows that send for a meaningful test 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 left as an exercise
for the operator).

Section 7 describes how the PCN architecture has been designed
alternative to
ensure admitted flows continue gracefully after recovering
automatically from running links at low utilisation in order to
protect against link or node failures. The need to record and
monitor re-routing events affecting signalling This is unchanged by especially the
addition of PCN to
case with SRLGs (shared risk link groups, which are links that
share a DiffServ domain. Similarly, re-routing events
within the PCN-domain will be recorded and monitored just resource, such as they
would be without PCN.

PCN-marking does make it possible to record 'near-misses'. For
instance, at the PCN-egress-node a 'reporting threshold' could be set
to monitor how often - and for how long - the system comes close to
triggering flow blocking without actually doing so. Similarly,
bursts fibre, whose failure affects all those
links [RFC4216]). Fully protecting traffic against a single SRLG
failure requires low utilisation (~10%) of flow termination marking could be recorded even if they are
not sufficiently sustained to trigger flow termination. Such
statistics could the link bandwidth on
some links before failure [Charny08].

o The PCN-supportable-rate may be correlated with per-queue counts of marking
volume (Section 9.2) to upgrade resources set below the maximum rate that
PCN-traffic can be transmitted on a link, in danger of causing
service degradation, or order to trigger manual tracing
termination of intermittent
incipient errors that would otherwise have gone unnoticed.

Finally, some PCN-flows before loss (or excessive delay) of course, many faults are caused by failings in
PCN-packets occurs, or to keep the
management process ('human error'): a wrongly configured address in a
node, a wrong address given in maximum PCN-load on a signalling protocol, link
below a wrongly level configured parameter in a queueing algorithm, a node set into a
different mode by the operator.

o Provisioning of the network is decoupled from other nodes, 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 on. Generally, the operator has to
verify provision is sufficient each time a clean
design with few configurable options ensures this class of faults new customer is added
to check that the Service Level Agreement can be traced more easily fulfilled. A
PCN-domain doesn't need such traffic conditioning.

12.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 prevented more often. Sound management
practice at run-time also helps. For instance: a management system
assumptions are, how many PCN encoding states are available, and so

Eardley (Editor) Expires July 18, September 17, 2009 [Page 34] 42]

Internet-Draft PCN Architecture January March 2009

should be used that constrains configuration changes within system
rules (eg preventing

on.

A PCN-domain may have three encoding states (or pedantically, an option setting inconsistent with other
nodes); configuration options should also
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 recorded supported. As
illustrated in an offline
database; and regular automatic consistency checks between live
systems and Figure 1, admission control accepts new flows until
the database should be performed. PCN adds nothing
specific PCN-traffic rate on the bottleneck link rises above the PCN-
threshold-rate, whilst if necessary the flow termination mechanism
terminates flows down to this class of problems.

9.5. Security OAM

Security OAM is about using secure operational practices 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 well 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
being able to track security breaches or near-misses at run-time.
PCN adds few specifics to
sessions end, PCN-traffic naturally reduces, and meanwhile the general good practice required in this
field [RFC4778], other than those below.
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 correct functions drawback of
the system should this
approach would be monitored (Section 9.2) in multiple independent
ways and correlated that, until sufficient sessions have ended to detect possible security breaches. Persistent
(pre-)congestion marking should raise an alarm (both on the node
doing the marking and on
relieve the PCN-egress-node metering it).
Similarly, persistently poor external QoS metrics such congestion, all PCN-flows as jitter or
MOS should raise well as lower priority
services will be adversely affected.

Second, an alarm. The following are examples operator could just rely for admission control on
statically provisioned capacity per PCN-ingress-node (regardless of symptoms
that may be
the result PCN-egress-node of innocent faults, rather than attacks, but
until diagnosed they should be logged and trigger a security alarm:

o Anomalous patterns flow), as is typical in the hose model of non-conforming incoming signals and packets
rejected at
the PCN-ingress-nodes (eg packets already marked PCN-
capable, or DiffServ architecture [RFC2475]. Such traffic persistently starving token bucket policers).

o PCN-capable packets arriving at conditioning
agreements can lead to focused overload: many flows happen to focus
on a PCN-egress-node with no
associated state for mapping them 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 valid ingress-egress-
aggregate.

o A PCN-ingress-node receiving feedback signals 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.

Within the PCN-domain there is some flexibility about how the pre-
congestion level on a non-existent aggregate, or that
decision making functionality is distributed. These possibilities
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.

10. IANA Considerations

This memo includes no request outlined in Section 4.4 and also discussed elsewhere, such as in
[Menth08-3].

The flow admission and termination decisions need to IANA. be enforced
through per flow policing by the PCN-ingress-nodes. If there are

Eardley (Editor) Expires July 18, September 17, 2009 [Page 35] 43]

Internet-Draft PCN Architecture January March 2009

11. Security considerations

Security considerations essentially come from the Trust Assumption
(Section 5.1), ie that all PCN-nodes are PCN-enabled and are trusted
for truthful PCN-marking and transport. PCN splits functionality
between PCN-interior-nodes and PCN-boundary-nodes, and the security
considerations are somewhat different for each, mainly because PCN-
boundary-nodes are flow-aware and PCN-interior-nodes are not.

o Because the PCN-boundary-nodes are flow-aware, they are trusted to
use that awareness correctly. The degree of trust required
depends

several PCN-domains on the kinds of decisions they have to make and the kinds
of information they need to make them. There is nothing specific end-to-end path, then each needs to PCN.

o The PCN-ingress-nodes police packets to ensure a PCN-flow sticks
within
at its agreed limit, and 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. This PCN-ingress-nodes. One exception is
similar to if the operator runs both
the existing IntServ behaviour. Between them access network (not a PCN-domain) and the core network (a PCN-
boundary-nodes must encircle the PCN-domain, otherwise PCN-packets
domain); per flow policing could enter the PCN-domain without being subject be devolved to admission
control, which would potentially destroy the QoS of existing
flows.

o PCN-interior-nodes are access network
and not flow-aware. This prevents some
security attacks where an attacker targets specific flows in done at the
data plane - for instance for DoS or eavesdropping.

o The PCN-boundary-nodes rely on correct PCN-marking PCN-ingress-node. Note: to aid readability, the
rest of this draft assumes that policing is done by the PCN-
interior-nodes. PCN-ingress-
nodes.

PCN admission control has to fit with the overall approach to
admission control. For instance a rogue PCN-interior-node could PCN-
mark all packets so that no flows were admitted. Another
possibility is that it doesn't PCN-mark any packets, even when it [Briscoe06] describes the case where
RSVP signalling runs end-to-end. The PCN-domain is pre-congested. More subtly, a single RSVP
hop, ie only the rogue PCN-interior-node could
perform these attacks selectively PCN-boundary-nodes process RSVP messages, with RSVP
messages processed on particular flows, or it could
PCN-mark each hop outside the correct fraction overall, but carefully choose which
flows it marked.

o The PCN-boundary-nodes should PCN-domain, as in IntServ
over DiffServ [RFC2998]. It would also be able possible for the RSVP
signalling to deal be originated and/or terminated by proxies, with DoS attacks
application-layer signalling between the end user and
state exhaustion attacks based on fast changes in per flow
signalling.

o The the proxy (eg
SIP signalling with a home hub). A similar example would use NSIS
signalling between instead of RSVP. (NSIS: Next Steps in Signalling,
[RFC3726].)

It is possible that a user wants its inelastic traffic to use the PCN-boundary-nodes must be protected
from attacks. For example PCN
mechanisms but also react to ECN marking outside the recipient needs PCN-domain
[Sarker08]. Two possible ways to validate do this are to tunnel all PCN-
packets across the PCN-domain, so that the message is indeed from ECN marks are carried
transparently across the node that claims PCN-domain, or to have sent it.
Possible measures include digest authentication and protection
against replay and man-in-the-middle attacks. For the specific

Eardley (Editor) Expires July 18, 2009 [Page 36]

Internet-Draft PCN Architecture January 2009

protocol RSVP, hop-by-hop authentication use an encoding like
[Moncaster08]. Tunnelling is discussed further in [RFC2747], Section 4.7.

Some further possible deployment models are outlined in the Appendix.

12.3. Assumptions and
[Behringer07] may also be useful.

Operational security advice constraints on scope

The scope is given restricted by the following assumptions:

1. these components are deployed in Section 9.5.

12. Conclusions

The document describes a general architecture single DiffServ domain, within
which all PCN-nodes are PCN-enabled and are trusted for flow admission truthful
PCN-marking and
termination based on pre-congestion information in order to protect
the quality of service of established inelastic transport

2. all flows within handled by these mechanisms are inelastic and
constrained to a single
DiffServ domain. The main topic is the functional architecture. It
also mentions other topics like known peak rate through policing or shaping

3. the assumptions and open issues.

13. Acknowledgements

This document number of PCN-flows across any potential bottleneck link is a revised version
sufficiently large that stateless, statistical mechanisms can be
effective. To put it another way, the aggregate bit rate of an earlier individual draft
authored by: P. Eardley, J. Babiarz, K. Chan, A. Charny, R. Geib, G.
Karagiannis, M. Menth, T. Tsou. They are therefore contributors to
this document.

Thanks PCN-
traffic across any potential bottleneck link needs to those who have made comments on this document: Lachlan
Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake, Scott
Bradner, Bob Briscoe, Jason Canon, Ken Carlberg, Anna Charny, Joachim
Charzinski, Andras Csaszar, Lars Eggert, Ruediger Geib, Wei Gengyu,
Robert Hancock, Fortune Huang, Christian Hublet, Ingemar Johansson,
Georgios Karagiannis, Hein Mekkes, Michael Menth, Toby Moncaster,
Daisuke Satoh, Ben Strulo, Tom Taylor, Hannes Tschofenig, Tina Tsou,
Lars Westberg, Magnus Westerlund, Delei Yu. Thanks be
sufficiently large relative to Bob Briscoe
who extensively revised the Operations and Management section. maximum additional bit rate
added by one flow. This document is the result basic assumption of measurement-
based admission control.

Eardley (Editor) Expires September 17, 2009 [Page 44]

Internet-Draft PCN Architecture March 2009

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

12.3.1. Assumption 1: Trust and
forerunner activity in the TSVWG. A number support of previous drafts were
presented to TSVWG; their authors were: B, Briscoe, P. Eardley, D.
Songhurst, F. Le Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley,
G. Karagiannis, A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G.
Liu, A. Bhargava.

14. Comments Solicited

Comments PCN - controlled environment

We assume that the PCN-domain is a controlled environment, ie all the
nodes in a PCN-domain run PCN and questions are encouraged and very welcome. They can trusted. There are several
reasons this assumption:

o The PCN-domain has to be
addressed encircled by a ring of PCN-boundary-
nodes, otherwise traffic could enter a PCN-BA without being
subject to admission control, which would potentially degrade the IETF PCN working group mailing list <pcn@ietf.org>.

Eardley (Editor) Expires July 18, 2009 [Page 37]

Internet-Draft PCN Architecture January 2009

15. Changes

15.1. Changes from -08
QoS of existing PCN-flows.

o Similarly, a PCN-boundary-node has to -09

Small changes trust that all the PCN-nodes
mark PCN-traffic consistently. A node not performing PCN-marking
wouldn't be able to deal with WG Chair comments:

o tweak language in 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 places attacks, as discussed in the Security Considerations
section.

One way of assuring the above two points is that the entire PCN-
domain is run by a single operator. Another possibility is that
there are several operators that trust each other in their handling
of PCN-traffic.

Note: All PCN-nodes need to make be trustworthy. However if it more RFC-like and less is known
that of a scholarly work, an interface cannot become pre-congested then it is not strictly
necessary for instance from "we propose" it to "this
document describes"

o tweak language be capable of PCN-marking. But this must be
known even in various places to make it a stand alone
architecture document rather than a discussion unusual circumstances, eg after the failure of some
links.

12.3.2. Assumption 2: Real-time applications

We assume that any variation of source bit rate is independent of the PCN WG. Now
only mentions WG
level of pre-congestion. We assume that PCN-packets come from real
time applications generating inelastic traffic, ie sending packets at start
the rate the codec produces them, regardless of Annex.

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

o References: removed some availability of less important references to IDs

15.2. Changes from -07 to -08

Small changes from second WG last call:

o Section 2: added definition for PCN-admissible-rate
capacity [RFC4594]. For example, voice 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 video requiring low
delay, jitter and packet loss, the Controlled Load Service,
[RFC2211], and the Telephony service class, [RFC4594]. This
assumption is to Figs 1 & 2.

o added help focus the phrase "(others might effort where it looks like PCN would
be possible") before most useful, ie the list sorts of
approaches in Section 6.3, 7.4 & 7.5.

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

o throughout, updated references now that marking behaviour &
baseline encoding are WG drafts.

o applications where per flow QoS is a few typos corrected

15.3. Changes from -06
known requirement. In other words we focus on PCN providing a
benefit to -07

References re-formatted inelastic traffic (PCN may or may not provide a benefit to pass ID nits. No
other changes.

15.4. Changes from -05 to -06

Minor clarifications throughout, the least insignificant are as
follows: types of traffic).

Eardley (Editor) Expires July 18, September 17, 2009 [Page 38] 45]

Internet-Draft PCN Architecture January March 2009

o Section 1: added

As a consequence, it is assumed that PCN-marking is being applied to
traffic scheduled with the list of encoding states in an 'extended'
scheme: "or perhaps further encoding states as suggested expedited forwarding per-hop behaviour,
[RFC3246], or a per-hop behaviour with similar characteristics.

12.3.3. Assumption 3: Many flows and additional load

We assume that there are many PCN-flows on any bottleneck link in
draft-westberg-pcn-load-control"

o Section 2: the
PCN-domain (or, to put it another way, the aggregate bit rate of PCN-
traffic across any potential bottleneck link is sufficiently large
relative to the maximum additional bit rate added definition for PCN-colouring (to clarify by one PCN-flow).
Measurement-based admission control assumes that the
term present is used consistently differently from 'PCN-marking')

o Section 6.1 and 6.2: added "(others might be possible)" before a
reasonable prediction of the
list future: the network conditions are
measured at the time of high level approaches for making a new flow admission
(termination) decisions.

o Section 6.2: corrected request, however the actual
network performance must be acceptable during the call some time
later. One issue is that if there are only a significant typo in 2nd bullet (more ->
less)

o Section 6.3: corrected few variable rate
flows, then the aggregate traffic level may vary a couple of significant typos in Figure 2

o Section 6.5 (PCN-traffic) re-written for clarity. Non PCN-traffic
contributing lot, perhaps
enough to PCN meters cause some packets to get dropped. If there are many flows
then the aggregate traffic level should be statistically smoothed.
How many flows is now given enough depends on a number of factors such as 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
variation in each flow's rate, the PCN-domain: "Note: A tunnel will total rate of PCN-traffic, and the
size of the "safety margin" between the traffic level at which we
start admission-marking and at which packets are dropped or
significantly delayed.

We do not provide this
behaviour if it complies with [RFC3168] tunnelling make explicit assumptions on how many PCN-flows are in either mode,
but it will if each
ingress-egress-aggregate. Performance evaluation work may clarify
whether it complies with [RFC4301] IPSec tunnelling."

o Section 7.7: added mention of [RFC4301] is necessary to make any additional assumption on
aggregation at the text about
decapsulation being done within ingress-egress-aggregate level.

12.3.4. Assumption 4: Emergency use out of scope

PCN-flows may have different precedence, but the PCN-domain.

o Section 8: deleted applicability of the text
PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc) is out
of scope of this document.

12.4. Challenges

Prior work on PCN and similar mechanisms has thrown up a number of
considerations about PCN's design goals, since this is
already covered adequately earlier eg goals (things PCN should be good
at) and some issues that have been hard to solve in S3.

o Section 11: replaced the last sentence a fully
satisfactory manner. Taken as a whole it represents a list of bullet 1 by "There trade-
offs (it is
nothing specific to PCN."

o Appendix: added to open issues: possibility of automatically unlikely that they can all be 100% achieved) and
periodically probing.

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

15.5. Changes from -04 to -05

Minor nits removed perhaps
as follows:

o Further minor changes evaluation criteria to reflect help an operator (or the IETF) decide
between options.

The following are open issues. They are mainly taken from
[Briscoe06], which also describes some possible solutions. Note that baseline encoding is
consensus, standards track document, whilst there can
some may be
(experimental track) encoding extensions considered unimportant in general or in specific

Eardley (Editor) Expires July 18, September 17, 2009 [Page 39] 46]

Internet-Draft PCN Architecture January March 2009

deployment scenarios or by some operators.

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

o Traffic conditioning updated to reflect discussions in Dublin,
mainly ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion
is measured on a specific ingress-egress-aggregate. However, if
the PCN-domain runs ECMP, 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: a new flow is admitted (because the pre-
congestion level measured by the PCN-egress-node is
sufficiently diluted by unmarked packets from non-congested
paths that PCN-interior-nodes don't police PCN-traffic (so
deleted bullet in S7.1) and a new flow is admitted), but its packets travel
through a 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 it 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 the (pre-)congested router(s). Since
flow termination is not advised a 'last resort', which protects the
network should over-admission occur, this problem is probably
more important to have non
PCN-traffic that shares solve than the same capacity (on a link) as PCN-
traffic (so added bullet in S6.5) other two.

o Probing moved into Appendix A ECMP and deleted the 'third viewpoint'
(admission control based on signalling: It is possible that, in a PCN-domain running
ECMP, the marking of signalling packets (eg RSVP, NSIS) follow a single packet like an
RSVP PATH message) - since different
path than the data packets, which could matter if the signalling
packets are used as probes. Whether this isn't really probing, and in any
case is already mentioned in S6.1.

o Minor changes to S9 Operations and management - mainly to reflect
that consensus an issue depends on marking behaviour has simplified things so eg
there are fewer parameters to configure.

o A few terminology-related errors expunged, and two pictures added
to help.

o Re-phrased
which fields the claim about ECMP algorithm uses; if the natural decision point in S7.4

o Clarified that extended encoding schemes need ECMP algorithm is
restricted to explain their
interactions with (or assumptions about) tunnelling (S7.7) and how
they meet the guidelines source and destination IP addresses, then it
will not be an issue. ECMP and signalling interactions are a
specific instance of BCP124 (S6.6)

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

15.6. Changes from -03 to -04 a general issue for non-traditional routing
combined with resource management along a path [Hancock02].

o Minor changes throughout Tunnelling: There are scenarios where tunnelling makes it
difficult to reflect determine the consensus call about PCN-
marking (as reflected path in [PCN08-2]).

o Minor changes throughout to reflect the current decisions about
encoding (as reflected in [PCN08-1] PCN-domain. The problem,
its impact, and [Moncaster08]).

o Introduction: re-structured the potential solutions are similar to create new sections on Benefits,
Deployment scenarios and Assumptions. those for
ECMP.

o Introduction: Added pointers to other Scenarios with only one tunnel endpoint in the PCN documents.

o Terminology: changed PCN-lower-rate to PCN-threshold-rate and PCN-
upper-rate to PCN-excess-rate; excess-rate-marking domain may make
it harder for the PCN-egress-node to excess-
traffic-marking.

o Benefits: added bullet about SRLGs.

o Deployment scenarios: new section combining material gather from various
places within the document. signalling
messages (eg RSVP, NSIS) the identity of the PCN-ingress-node.

Eardley (Editor) Expires July 18, September 17, 2009 [Page 40] 47]

Internet-Draft PCN Architecture January March 2009

o S6 (high level functional architecture): re-structured and edited
to improve clarity, and reflect the latest PCN-marking and
encoding drafts.

o S6.4: added claim 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 only makes sense if microflows in both directions are
admitted. However, the most natural place to make an PCN mechanisms concern admission and
termination of a single flow, and coordination of the decision for
both flows is a PCN-egress-node.

o S6.5: updated the bullet about non-PCN-traffic that uses matter for 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 signalling protocol and out of
scope of PCN. One possible example would use SIP pre-conditions.
However, there are others.

o Probing: moved to Appendix B.

o Other minor clarifications, typos etc.

15.7. Changes 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 -02 a global perspective, it would be
better to -03

o Abstract: Clarified by removing make a coordinated decision across all the term 'aggregated'. Follow-up
clarifications later in draft: S1: expanded PCN-egress-nodes
bullet to mention case where ingress-
egress-aggregates for the PCN-feedback-information is about
one whole PCN-domain. For example, to block
(or even terminate) flows on one ingress-egress-aggregate so that
more important flows through a few) PCN-marks, rather than aggregated information; S3
clarified PCN-meter; S5 minor changes; conclusion. different ingress-egress-aggregate
could be admitted. The problem may well be relatively
insignificant.

o S1: added a paragraph about how Aggregate Traffic Characteristics: Even when the number of flows
is stable, the traffic level through the PCN-domain looks to will vary
because the
outside world (essentially it looks like sources vary their traffic rates. PCN works best when
there is not too much variability in the total traffic level at a DiffServ domain).

o S2: tweaked
PCN-node's interface (ie in the PCN-traffic terminology bullet: changed PCN aggregate traffic classes from all
sources). Too much variation means that a 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 PCN behaviour aggregates, tune
the admission control scheme to be stop admitting new flows at the
right time. Therefore the problem is more in line likely with traditional DiffServ jargon (-> follow-up changes later in
draft); included a definition of PCN-flows (and corrected a couple
of 'PCN microflows' to 'PCN-flows' later in draft) fewer,
burstier flows.

o S3.5: added possibility Flash crowds and Speed of downgrading to best effort, where PCN-
packets arrive at PCN-ingress-node already ECN marked (CE or ECN
nonce)

o S4: added note about whether talk about Reaction: PCN operating on is a measurement-based
mechanism and so there is an
interface or on inherent delay between packet marking
by PCN-interior-nodes and any admission control reaction at PCN-
boundary-nodes. For example, potentially if a link. In S8.1 (OAM) mentioned that PCN
functionality needs to be configured consistently on either the
ingress or the egress interface big burst of PCN-nodes
admission requests occurs in a PCN-domain.

o S5.2: clarified that signalling protocol installs flow filter spec
at PCN-ingress-node (& updates after possible re-route)

Eardley (Editor) Expires July 18, 2009 [Page 41]

Internet-Draft PCN Architecture January 2009

o S5.6: addressing: clarified

o S5.7: added tunnelling issue very short space of N^2 scaling if you set up time (eg
prompted by a mesh
of tunnels between PCN-boundary-nodes

o S7.3: Clarified 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 "third viewpoint" reaction time of probing (always probe).

o S8.1: clarified that SNMP is only an example; added note that an
operator the mechanism
must not move the PCN-domain directly from a no congestion state
to 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 requests able to not run arrive within the
vulnerability period.

Eardley (Editor) Expires September 17, 2009 [Page 48]

Internet-Draft PCN on Architecture March 2009

o Silent at start: after a successful admission request the source
may wait some PCN-interior-nodes, if
it knows that these links 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 never become (pre-)congested; added
note that it may be possible to have different PCN-boundary-node
behaviours for different ingress-egress-aggregates within when the same
PCN-domain.

o Appendix: Created an source does start sending data.

13. Appendix about "Possible B: Possible future work items beyond

13.1. Benefits

We believe that the scope key benefits of the current PCN WG Charter". Material moved from
near start of S3 mechanisms described in
this document are that they are simple, scalable, and elsewhere throughout draft. Moved text about
centralised decision node to Appendix. robust because:

o Other minor clarifications.

15.8. Changes 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 -01 to -02 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 S1: Benefits: provisioning bullet extended to stress 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 PCN does
not use RFC2475-style admitted traffic conditioning.

o S1: Deployment models: mentioned, can still be carried after a
rerouting in most failure cases [Menth07]. This is an important
feature as variant of PCN-domain
extending QoS violations in core networks due to end nodes, that may extend link failures
are more likely than QoS violations due to LAN edge switch. increased traffic
volume [Iyer03].

o S3.1: Trust Assumption: added note about not needing The PCN-marking
capability if known that an interface cannot become pre-congested.

o S4: now divided into sub-sections behaviours only operate on the overall PCN-traffic
on the link, not per flow.

o S4.1: Admission control: added second proposed method for how to
decide The information of these measurements is signalled to block new flows (PCN-egress-node receives one (or
several) PCN-marked packets).

o S5: Probing sub-section removed. Material now the PCN-
egress-nodes by the PCN-marks in new S7. 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 S5.6: Addressing: clarified how PCN-ingress-node can discover
address of 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

o S5.6: Addressing: centralised node case, added that PCN-ingress-
node may need to know address of PCN-egress-node

o S5.8: Tunnelling: added case PCN-feedback-
information (which is used for flow admission and termination
decisions) is at the granularity of "partially PCN-capable tunnel" the ingress-egress-aggregate.
An alternative approach is that the PCN-egress-nodes monitor the
PCN-traffic and
degraded bullet on this in S6 (Open Issues) signal PCN-feedback-information (which is used for
flow admission and termination decisions) at the granularity of

Eardley (Editor) Expires July 18, September 17, 2009 [Page 42] 49]

Internet-Draft PCN Architecture January March 2009

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

15.9. Changes from -00 to -01

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

o S1: Benefits: added

one about provisioning (and contrast with
DiffServ SLAs) (or a few) PCN-marks.

o S1: Benefits: clarified that the objective The admitted PCN-load is controlled dynamically. Therefore it
adapts as the traffic matrix changes, and also to stop PCN-
packets being significantly delayed (previously only mentioned not
dropping packets)

o S1: Deployment models: added one where policing is done at ingress
of access if the network
topology changes (eg after a link failure). Hence an operator can
be less conservative when deploying network capacity, and not at ingress less
accurate in their prediction of PCN-domain (assume trust
between networks) the PCN-traffic matrix.

o S1: Deployment models: corrected MPLS-TE The termination mechanism complements admission control. It
allows the network to MPLS

o S2: Terminology: adjusted definition recover from sudden unexpected surges of PCN-domain

o S3.5: Other assumptions: corrected, so that two assumptions (PCN-
nodes not performing ECN and PCN-ingress-node discarding arriving
CE packet) only apply if
PCN-traffic on some links, thus restoring QoS to the PCN WG decides 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 encode PCN-marking other links, or by malfunction of the
measurement-based admission control in the ECN-field.

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

o S4: clarified presence of admitted
flows that PCN-interior-node functionality applies send for
each outgoing interface, a while with an atypically low rate and added clarification: "The
functionality is also done by PCN-ingress-nodes for then
increase their outgoing
interfaces (ie those 'inside' the PCN-domain)." rates in a correlated way.

o S4 (near end): altered Flow termination can also enable an operator to say 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 PCN-node "should" dedicate
some capacity to lower priority resource, such as a fibre, whose failure affects all those
links [RFC4216]). Fully protecting traffic so that it isn't starved
(was "may") against a single SRLG
failure requires low utilisation (~10%) of the link bandwidth on
some links before failure [Charny08].

o S5: clarified to say The PCN-supportable-rate may be set below the maximum rate that PCN functionality is done on an
'interface' (rather than
PCN-traffic can be transmitted on a 'link')

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

Eardley (Editor) Expires July 18, 2009 [Page 43]

Internet-Draft PCN Architecture January 2009

o S5.5: Probing: re-written, especially link, in order to distinguish probing trigger
termination of some PCN-flows before loss (or excessive delay) of
PCN-packets occurs, or to
test keep the ingress-egress-aggregate from probing to test maximum PCN-load on a
particular ECMP path. link
below a level configured by the operator.

o S5.7: Addressing: added mention Provisioning of probing; added that in the case
where traffic network is always tunnelled across the PCN-domain, add a
note that he PCN-ingress-node needs to know decoupled from the address process of
adding new customers. By contrast, with the
PCN-egress-node.

o S5.8: Tunnelling: re-written, especially to provide a clearer
description of copying DiffServ architecture
[RFC2475] operators rely on tunnel entry/exit, by adding explanation
(keeping tunnel encaps/decaps and PCN-marking orthogonal),
deleting one bullet ("if subscription-time Service Level
Agreements, which statically define the inner header's marking state is more
sever then it is preserved" - shouldn't happen), and better
referencing parameters of other IETF documents.

o S6: Open issues: stressed the traffic
that "NOTE: Potential solutions are out
of scope for this document" and edited will be accepted from a couple of sentences that
were close to solution space.

o S6: Open issues: added one about scenarios with only one tunnel
endpoint in customer, and so 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"

o S10: Conclusions: operator has to
verify provision is sufficient each time a small conclusions section new customer is added

16. Appendix: Possible future work items
to check that the Service Level Agreement can be fulfilled. A
PCN-domain doesn't need such traffic conditioning.

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

Eardley (Editor) Expires September 17, 2009 [Page 50]

Internet-Draft PCN Architecture March 2009

NOTE: it should be crystal clear that this section discusses
possibilities only.

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

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

Eardley (Editor) Expires July 18, 2009 [Page 44]

Internet-Draft PCN Architecture January 2009

o 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
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 widely but not universally
deployed).

o applying the PCN mechanisms to other types of traffic, ie beyond
inelastic 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 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 applicability of PCN mechanisms for emergency use (911, GETS,
WPS, MLPP, etc.)

Other possibilities include:

o Probing. This is discussed in Section 16.1 13.1 below.

o The PCN-domain extends to the end users. The 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.

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

o 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-

Eardley (Editor) Expires September 17, 2009 [Page 51]

Internet-Draft PCN Architecture March 2009

node the decision about admission (or termination). It may need
the centralised node and the 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: the details of how the signalling protocol installs the
flowspec at the PCN-ingress-node for an admitted PCN-flow; and how
the signalling protocol carries the PCN-feedback-information.
Perhaps also for other functions such as: coping with failure of a

Eardley (Editor) Expires July 18, 2009 [Page 45]

Internet-Draft PCN Architecture January 2009
PCN-boundary-node ([Briscoe06] considers what happens if RSVP is
the QoS signalling protocol); establishing a tunnel across the
PCN-domain if it is necessary to carry ECN marks transparently.

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: PCN may be used as a congestion avoidance
mechanism for edge to edge pseudowire emulations [PWE3-08].

o PCN for MPLS: [RFC3270] defines how to support the DiffServ
architecture in MPLS networks (Multi-protocol label switching).
[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 [MPLS08] re-names the Class of Service
(CoS) field).

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

16.1.

13.2. Probing

16.1.1.

13.2.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 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.

Eardley (Editor) Expires September 17, 2009 [Page 52]

Internet-Draft PCN Architecture March 2009

However it's possible to envisage a scenario where the traffic levels
on other ingress-egress-aggregates are already so high that they're
blocking new PCN-flows, and admitting a new flow onto this 'empty'
ingress-egress-aggregate adds extra traffic onto a link that is
already pre-congested - which may 'tip the balance' so that PCN's
flow termination mechanism is activated or some packets are dropped.
This risk could be lessened by configuring on each link sufficient
'safety margin' above the PCN-threshold-rate.

An alternative approach is to make PCN a more proactive mechanism.

Eardley (Editor) Expires July 18, 2009 [Page 46]

Internet-Draft PCN Architecture January 2009
The PCN-ingress-node explicitly determines, before admitting the
prospective new flow, whether the ingress-egress-aggregate can
support it. This can be seen as a "pessimistic" approach, in
contrast to the "optimism" of the approach above. It involves
probing: a PCN-ingress-node generates and sends probe packets in
order to test the pre-congestion level that the flow would
experience.

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

16.1.2.

13.2.2. Probing functions

The probing functions are:

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

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

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

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

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

16.1.3.

Eardley (Editor) Expires September 17, 2009 [Page 53]

Internet-Draft PCN Architecture March 2009

13.2.3. Discussion of rationale for probing, its downsides and 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 is running in the PCN-domain. We now consider each in turn.

Eardley (Editor) Expires July 18, 2009 [Page 47]

Internet-Draft PCN Architecture January 2009

The first viewpoint assumes the following:

o There is no PCN-traffic on the ingress-egress-aggregate (so a
normal admission decision cannot be made).

o Simply admitting the new flow has a significant risk of leading to
overload: packets dropped or flows terminated.

On the former bullet, [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 this would probably have to happen in a
short time period (flash crowd) because, after the reaction time of
the system, other (non-empty) ingress-egress-aggregates that pass
through the link will measure pre-congestion and so block new flows.
Also, flows naturally end anyway.

The downsides of probing for this viewpoint are:

o Probing adds delay to the admission control process.

o Sufficient probing traffic has to be generated to test the pre-
congestion level of the ingress-egress-aggregate. But the probing
traffic itself may cause pre-congestion, causing other PCN-flows
to be blocked or even terminated - and in the flash crowd scenario
there will be probing on many ingress-egress-aggregates.

The second viewpoint applies in the case where there is multipath
routing (ECMP) in the PCN-domain. Note that ECMP is often used on
core networks. There are two possibilities:

(1) If admission control is based on measurements of the ingress-
egress-aggregate, then the viewpoint that probing is useful assumes:

Eardley (Editor) Expires September 17, 2009 [Page 54]

Internet-Draft PCN Architecture March 2009

o there's a significant chance that the traffic is unevenly balanced
across the ECMP paths, and hence there's a significant risk of
admitting a flow that should be blocked (because it follows an
ECMP path that is pre-congested) or blocking a flow that should be
admitted.

o Note: [Charny07-3] suggests unbalanced traffic is quite possible,
even with quite a large number of flows on a PCN-link (eg 1000)
when Assumption 3 (aggregation) is likely to be satisfied.

Eardley (Editor) Expires July 18, 2009 [Page 48]

Internet-Draft PCN Architecture January 2009

(2) If admission control is based on measurements of pre-congestion
on specific ECMP paths, then the viewpoint that probing is useful
assumes:

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

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

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

o Note: This is similar to the first viewpoint and so similarly
could occur in a flash crowd if a new flow starts more-or-less
simultaneously on many of the empty ECMP paths. Because there are
several (sometimes many) ECMP paths between each pair of PCN-
boundary-nodes, it's presumably more likely that an ECMP path is
'empty' than an ingress-egress-aggregate is. To constrain the
number of ECMP paths, a few tunnels could be set-up between each
pair of PCN-boundary-nodes. Tunnelling also solves the issue in
the bullet immediately above (which is otherwise hard because an
ECMP routing decision is made independently on each node).

The downsides of probing for this viewpoint are:

o Probing adds delay to the admission control process.

o Sufficient probing traffic has to be generated to test the pre-
congestion level of the ECMP path. But there's the risk that the
probing traffic itself may cause pre-congestion, causing other
PCN-flows to be blocked or even terminated.

o The PCN-egress-node needs to consume the probe packets to ensure
they don't travel beyond the PCN-domain, since they might confuse
the destination end node. This is non-trivial, since probe
packets are addressed to the destination end node, in order to
test the relevant ECMP path (ie they are not addressed to the PCN-
egress-node, unlike the first viewpoint above).

Eardley (Editor) Expires September 17, 2009 [Page 55]

Internet-Draft PCN Architecture March 2009

The open issues associated with this viewpoint include:

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

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

Eardley (Editor) Expires July 18, 2009 [Page 49]

Internet-Draft PCN Architecture January 2009

o Can the delay be alleviated by automatically and periodically
probing on the ingress-egress-aggregate? Or does this add too
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; 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 - but these
bits must not be used by any PCN-interior-node's ECMP algorithm.
In the general case this isn't possible, but it should be possible
for a typical ECMP algorithm (which examines: the source and
destination IP addresses and port numbers, the protocol ID, and
the DSCP).

17.

14. References

17.1.

14.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
Behavior)", RFC 3246, March 2002.

17.2.

14.2. Informative References

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

Eardley (Editor) Expires September 17, 2009 [Page 56]

Internet-Draft PCN Architecture March 2009

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
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 (Editor) Expires July 18, 2009 [Page 50]

Internet-Draft PCN Architecture January 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.

[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 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.

Eardley (Editor) Expires September 17, 2009 [Page 57]

Internet-Draft PCN Architecture March 2009

[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.

[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.

Eardley (Editor) Expires July 18, 2009 [Page 51]

Internet-Draft PCN Architecture January 2009
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
Marking in MPLS", RFC 5129, January 2008.

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

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

[MPLS08] "Multi-Protocol Label Switching (MPLS) label stack entry:
"EXP" field renamed to "Traffic Class" field (work in
progress)", Dec 2008.

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

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

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

Eardley (Editor) Expires September 17, 2009 [Page 58]

Internet-Draft PCN Architecture March 2009

[Babiarz06]
"SIP Controlled Admission and Preemption (work in
progress)", Oct 2006.

[Behringer07]
"Applicability of Keying Methods for RSVP Security (work
in progress)", Nov 2007.

[Briscoe06]
"An edge-to-edge Deployment Model for Pre-Congestion
Notification: Admission Control over a DiffServ Region
(work in progress)", October 2006.

[Briscoe08-1]
"Emulating Border Flow Policing using Re-PCN on Bulk Data

Eardley (Editor) Expires July 18, 2009 [Page 52]

Internet-Draft PCN Architecture January 2009
(work in progress)", Sept 2008.

[Briscoe08-2]
"Layered Encapsulation of Congestion Notification (work in
progress)", July 2008.

[Charny07-1]
"Comparison of Proposed PCN Approaches (work in
progress)", November 2007.

[Charny07-2]
"Pre-Congestion Notification Using Single Marking for
Admission and Termination (work in progress)",
November 2007.

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

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

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

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

[Iyer03] "An approach to alleviate link overload as observed on an

Eardley (Editor) Expires September 17, 2009 [Page 59]

Internet-Draft PCN Architecture March 2009

IP backbone", IEEE INFOCOM , 2003,
<http://www.ieee-infocom.org/2003/papers/10_04.pdf>.

[Lefaucheur06]
"RSVP Extensions for Admission Control over Diffserv using
Pre-congestion Notification (PCN) (work in progress)",
June 2006.

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

[Menth08-1]
"Edge-Assisted Marked Flow Termination (work in

Eardley (Editor) Expires July 18, 2009 [Page 53]

Internet-Draft PCN Architecture January 2009
progress)", February 2008.

[Menth08-2]
"PCN Encoding for Packet-Specific Dual Marking (PSDM)
(work in progress)", July 2008.

[Menth08-3]
"PCN-Based Admission Control and Flow Termination", 2008,
<http://www3.informatik.uni-wuerzburg.de/staff/menth/
Publications/Menth08-PCN-Comparison.pdf>.

[Moncaster08]
"A three state extended PCN encoding scheme (work in
progress)", June 2008.

[Sarker08]
"Usecases and Benefits of end to end ECN support in PCN
Domains (work in progress)", November 2008.

[Songhurst06]
"Guaranteed QoS Synthesis for Admission Control with
Shared Capacity", BT Technical Report TR-CXR9-2006-001,
Feburary 2006, <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.' and 'e.g.'), as in
many style guides, eg, 2007,
<http://www.guardian.co.uk/styleguide/>.

[Tsou08] "Applicability Statement for the Use of Pre-Congestion
Notification in a Resource-Controlled Network (work in
progress)", November 2008.

Eardley (Editor) Expires September 17, 2009 [Page 60]

Internet-Draft PCN Architecture March 2009

[Westberg08]
"LC-PCN: The Load Control PCN Solution (work in
progress)", November 2008.

Eardley (Editor) Expires July 18, 2009 [Page 54]

Internet-Draft PCN Architecture January 2009

Author's Address

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

Email: philip.eardley@bt.com

Eardley (Editor) Expires July 18, September 17, 2009 [Page 55] 61]

Internet-Draft PCN Architecture March 2009
----