WDIFF

draft-ietf-pcn-architecture-03.txt --> draft-ietf-pcn-architecture-04.txt

Congestion and Pre-Congestion Philip. Eardley (Editor)
Notification Working Group BT
Internet-Draft February 8, July 14, 2008
Intended status: Informational
Expires: August 11, 2008 January 15, 2009

Pre-Congestion Notification Architecture
draft-ietf-pcn-architecture-03
draft-ietf-pcn-architecture-04

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

This Internet-Draft will expire on August 11, 2008. January 15, 2009.

Abstract

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

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 1]

Internet-Draft Document February July 2008

Status

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 5
3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 8
5. Assumptions and constraints on scope . . . . . . . . . . . . . 9
3.1. 10
5.1. Assumption 1: Trust and support of PCN - controlled
environment . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. 11
5.2. Assumption 2: Real-time applications . . . . . . . . . . . 10
3.3. 11
5.3. Assumption 3: Many flows and additional load . . . . . . . 10
3.4. 12
5.4. Assumption 4: Emergency use out of scope . . . . . . . . . 11
3.5. Other assumptions 12
6. High-level functional architecture . . . . . . . . . . . . . . 12
6.1. Flow admission . . . . . . . 11
4. High-level functional architecture . . . . . . . . . . . . . . 11
4.1. Flow admission . 14
6.2. Flow termination . . . . . . . . . . . . . . . . . . . . . 12
4.2. 15
6.3. Flow admission and flow termination when there are
only two PCN encoding states . . . . . . . . . . . . . . . 16
6.4. Information transport . . . . . . 13
4.3. Flow admission and flow termination . . . . . . . . . . . 14
4.4. Information transport . 16
6.5. PCN-traffic . . . . . . . . . . . . . . . . . 15
4.5. PCN-traffic . . . . . . 17
6.6. Backwards compatibility . . . . . . . . . . . . . . . . . 15
5. 17
7. Detailed Functional architecture . . . . . . . . . . . . . . . 16
5.1. 18
7.1. PCN-interior-node functions . . . . . . . . . . . . . . . 17
5.2. 19
7.2. PCN-ingress-node functions . . . . . . . . . . . . . . . . 17
5.3. 19
7.3. PCN-egress-node functions . . . . . . . . . . . . . . . . 18
5.4. 20
7.4. Other admission control functions . . . . . . . . . . . . 19
5.5. 20
7.5. Other flow termination functions . . . . . . . . . . . . . 19
5.6. 21
7.6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20
5.7. 22
7.7. Tunnelling . . . . . . . . . . . . . . . . . . . . . . . . 21
5.8. 23
7.8. Fault handling . . . . . . . . . . . . . . . . . . . . . . 22
6. 24
8. Design goals and challenges . . . . . . . . . . . . . . . . . 23
7. Probing . 24
9. Operations and Management . . . . . . . . . . . . . . . . . . 27
9.1. Configuration OAM . . . . . . . . 25
7.1. Introduction . . . . . . . . . . . . 27
9.1.1. System options . . . . . . . . . . . 25
7.2. Probing functions . . . . . . . . . 28
9.1.2. Parameters . . . . . . . . . . . 26
7.3. Discussion of rationale for probing, its downsides and
open issues . . . . . . . . . . . 29
9.2. Performance & Provisioning OAM . . . . . . . . . . . . 27
8. Operations and Management . . 31
9.3. Accounting OAM . . . . . . . . . . . . . . . . 30
8.1. Configuration OAM . . . . . . 32
9.4. Fault OAM . . . . . . . . . . . . . . 30
8.1.1. System options . . . . . . . . . . 32
9.5. Security OAM . . . . . . . . . . 31
8.1.2. Parameters . . . . . . . . . . . . . 33
10. IANA Considerations . . . . . . . . . 31
8.2. Performance & Provisioning OAM . . . . . . . . . . . . 34
11. Security considerations . . 33
8.3. Accounting OAM . . . . . . . . . . . . . . . . . 34
12. Conclusions . . . . . 34
8.4. Fault OAM . . . . . . . . . . . . . . . . . . . . 35
13. Acknowledgements . . . . 34
8.5. Security OAM . . . . . . . . . . . . . . . . . . . 35
14. Comments Solicited . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . 36
15. Changes . . . 36
10. Security considerations . . . . . . . . . . . . . . . . . . . 36
11. Conclusions . . . . . 36
15.1. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 36

Eardley (Editor) Expires January 15, 2009 [Page 2]

Internet-Draft Document July 2008

15.2. Changes from -02 to -03 . . . . . . . . . . . 37
12. Acknowledgements . . . . . . 37
15.3. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 38
13. Comments Solicited
15.4. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 39
16. Appendix A: Possible work items beyond the scope of the
current PCN WG Charter . . . . . 38

Eardley (Editor) Expires August 11, 2008 [Page 2]

Internet-Draft Document February 2008

14. Changes . . . . . . . . . . . . . . . 40
17. Appendix B: Probing . . . . . . . . . . . . 38
14.1. Changes from -02 to -03 . . . . . . . . . 42
17.1. Introduction . . . . . . . . 38
14.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 42
17.2. Probing functions . . 39
14.3. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 40
15. Appendix A: Possible work items beyond the scope . 43
17.3. Discussion of the
current PCN WG Charter rationale for probing, its downsides and
open issues . . . . . . . . . . . . . . . . . . . . 42
16. . . . 43
18. Informative References . . . . . . . . . . . . . . . . . . . . 44 46
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 51
Intellectual Property and Copyright Statements . . . . . . . . . . 48 52

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 3]

Internet-Draft Document February July 2008

1. Introduction

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

As a fundamental building block to enable these two mechanisms, PCN-
interior-nodes generate, encode and transport pre-congestion
information towards the PCN-egress-nodes. Two rates, a PCN-lower-
rate PCN-
threshold-rate and a PCN-upper-rate, can be PCN-excess-rate, are associated with each link
of the PCN-domain. Each rate is used by a marking behaviour (specified in
another document) that
determines how and when a number of PCN-
packets PCN-packets are marked, and how the markings
are encoded in packet headers. PCN-egress-nodes make measurements of the packet markings
and send information as necessary to the nodes that make the decision
about which PCN-flows to accept/reject or terminate, based on this
information. Another document will describe the decision-making
behaviours. Overall the aim is to enable PCN-nodes PCN-
nodes to give an "early warning" of potential congestion before there
is any significant build-up of PCN-packets in the queue; the queue.

PCN-boundary-nodes convert measurements of these PCN-markings into
decisions about flow admission and termination. The admission
control mechanism limits the PCN-traffic on each link to *roughly*
its PCN-lower-rate PCN-threshold-rate and the flow termination mechanism limits the
PCN-traffic on each link to *roughly* its PCN-upper-rate.

We believe that the key benefits of PCN-excess-rate.

This document describes the PCN mechanisms described in
this document are that they are simple, scalable, architecture and robust because:

o Per flow state outlines some
benefits, deployment scenarios, assumptions and terminology for PCN.
The behaviour of PCN-interior-nodes is only required at standardised in three
documents, which are summarised in this
document.[I-D.eardley-pcn-marking-behaviour] standardises the PCN-ingress-nodes
("stateless core"). This is required for policing purposes (to
prevent non-admitted PCN two
marking behaviours of PCN-nodes: threshold marking and excess traffic from entering
marking. Threshold marking marks all PCN-packets if the PCN-domain) and
so on. It PCN traffic
rate is not generally required greater than a first configured rate, "PCN-threshold-rate".
Excess traffic marking marks a proportion of PCN-packets, such that other network entities
are aware
the amount marked equals the traffic rate in excess of individual flows (although they may be a second
configured rate, "PCN-excess-rate". PCN encoding uses a combination
of the DSCP field and ECN field in particular
deployment scenarios). the IP header to indicate that a
packet is a PCN-packet and whether it is PCN-marked.

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 4]

Internet-Draft Document February July 2008

o Admission control is resilient: PCN's QoS is decoupled from the
routing system; hence in general admitted flows can survive
capacity, routing or topology changes without additional
signalling,

[I-D.moncaster-pcn-baseline-encoding] standardises two PCN encoding
states (PCN-marked and they don't have to be told (or learn) about such
changes. The PCN-lower-rates can be chosen small enough that
admitted traffic can still be carried after a rerouting in most
failure cases [Menth]. This is not PCN-marked) whilst
[I-D.moncaster-pcn-3-state-encoding] standardises an important feature as QoS
violations in core networks due to link failures are more likely
than QoS violations due to increased traffic volume [Iyer].

o The PCN-marking behaviours only operate on extended scheme
with three encoding states (threshold-marked, excess-traffic-marked,
not PCN-marked) but requires an extra DiffServ codepoint. PCN
therefore defines semantics for the overall PCN-traffic
on ECN field different from the link, not per flow.

o The information
default semantics of these measurements is signalled [RFC3168]; PCN's encoding has been chosen to
meet the guidelines of BCP124, [RFC4774]. The behaviour of PCN-
egress-nodes by the PCN-marks in the packet headers, ie "in-band".
No additional signalling protocol is required for transporting the
PCN-marks. Therefore no secure binding
boundary-nodes is required between data
packets described in Informational documents. Several
possibilities are outlined in this document; detailed descriptions
and separate congestion messages. comparisons are in [I-D.charny-pcn-comparison] and [Menth08].

2. Terminology

o The PCN-egress-nodes make separate measurements, operating on the
aggregate PCN-traffic from each PCN-ingress-node, ie not per flow.
Similarly, signalling by PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled
nodes that perform DiffServ scheduling; the PCN-egress-node complete set of PCN-feedback-
information (which is used for PCN-
nodes whose PCN-marking can in principle influence decisions about
flow admission and termination
decisions) is at the granularity of for the ingress-egress-aggregate.
An alternative approach is that PCN-domain, including the
PCN-egress-nodes monitor the
PCN-traffic and signal PCN-feedback-information (which is used for
flow admission and termination decisions) at the granularity of which measure these PCN-marks.

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

o The admitted PCN-load PCN-interior-node: a node in a PCN-domain that is controlled dynamically. Therefore 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
adapts leaves a PCN-domain.

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

o PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic matrix changes, of
different DiffServ behaviour aggregates (BAs) [RFC2475]. The
PCN-BA uses the PCN mechanisms to carry PCN-traffic and also if the
corresponding packets are PCN-packets. The same network
topology changes (eg after will
carry traffic of other DiffServ BAs. The PCN-BA is distinguished
by a link failure). Hence an operator can
be less conservative when deploying network capacity, and less
accurate in their prediction combination of the PCN-traffic matrix.

o The termination mechanism complements admission control. It
allows DiffServ codepoint (DSCP) and ECN fields;
note that a packet that shares the network to recover from sudden unexpected surges of same DSCP as PCN-traffic on some links, thus restoring QoS to the remaining
flows. Such scenarios are expected to be rare but
its ECN field is 00 (Not ECT) is not impossible.
They can be caused by large network failures that redirect lots of
admitted PCN-traffic to other links, or by malfunction part of the
measurement-based admission control in PCN-BA.

o PCN-flow: the presence unit of admitted
flows PCN-traffic that send for a while with an atypically low rate and then
increase their rates in a correlated way.

o The PCN-upper-rate may be set below the maximum rate that PCN-
traffic can PCN-boundary-node
admits (or terminates); the unit could be transmitted on a link, single microflow (as
defined in order to trigger
termination of [RFC2475]) or some PCN-flows before loss (or excessive delay) identifiable collection of
microflows.

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 5]

Internet-Draft Document February July 2008

o Ingress-egress-aggregate: The collection of PCN-packets occurs, or to keep the maximum PCN-load on from all
PCN-flows that travel in one direction between a link
below specific pair of
PCN-boundary-nodes.

o PCN-threshold-rate: a level reference rate configured for each link in
the PCN-domain, which is lower than the PCN-excess-rate. It is
used by a marking behaviour that determines whether a packet
should be PCN-marked with a first encoding, "threshold-marked".
It's roughly the operator. rate up to which PCN admission control should
accept new flows.

o Provisioning of PCN-excess-rate: a reference rate configured for each link in the network
PCN-domain, which is decoupled from higher than the process of
adding new customers. By contrast, PCN-threshold-rate. It is
used by a marking behaviour that determines whether a packet
should be PCN-marked with a second encoding, "excess-traffic-
marked". It's roughly that rate down to which flow termination
should, if necessary, terminate already admitted flows.

o Threshold-marking: a PCN-marking behaviour with the DiffServ architecture
[RFC2475] operators rely on subscription-time Service Level
Agreements objective that statically define
all PCN-traffic is marked if the parameters PCN-traffic exceeds the PCN-
threshold-rate.

o Excess-traffic-marking: a PCN-marking behaviour with the objective
that the amount of PCN-traffic that is PCN-marked is equal to the traffic
amount that will be accepted from exceeds the PCN-excess-rate.

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

o PCN-marking: the provisioning process each time of setting the header in a new customer is added PCN-packet
based on defined rules, in reaction to
check pre-congestion; either
threshold-marking or excess-traffic-marking.

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

3. Benefits

We believe that the Service Level Agreement can be fulfilled. A PCN-
domain doesn't need such traffic conditioning.

Operators key benefits of networks will want to use the PCN mechanisms described in various
arrangements, for instance depending on how they
this document are performing
admission control outside the PCN-domain (users after all that they are
concerned about QoS end-to-end), what their particular goals and
assumptions are, simple, scalable, and so on. Several deployment models are possible: robust because:

o An operator may choose to deploy either admission control or Per flow
termination or both (see Section 4.3).

o IntServ over DiffServ [RFC2998]. The DiffServ region is PCN-
enabled and the PCN-domain state is a single RSVP hop, ie only the PCN-
boundary-nodes process RSVP messages. Outside the PCN-domain RSVP
messages are processed on each hop. The case where RSVP
signalling is used end-to-end is described in
[I-D.briscoe-tsvwg-cl-architecture]; it would also be possible for
the RSVP signalling to be originated and/or terminated by proxies,
with application-layer signalling between the end user and the
proxy (eg SIP signalling with a home hub).

o Similar to previous bullet but NSIS signalling is used instead of
RSVP.

o Depending on the deployment scenario, the decision-making
functionality (about flow admission and termination) could reside required at the PCN-ingress-nodes or PCN-egress-nodes or (see Appendix) at
some central control node in the PCN-domain.

o There are several PCN-domains on the end-to-end path, each
operating PCN mechanisms independently.

o The PCN-domain extends to the end users. The scenario is
described in [I-D.babiarz-pcn-sip-cap]. A variant
("stateless core"). This is that the
PCN-domain extends out as far as the LAN edge switch.

o The operator runs both the access network (not a PCN-domain) and
the core network (a PCN-domain); per flow required for policing is devolved to purposes (to

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 6]

Internet-Draft Document February July 2008

prevent non-admitted PCN traffic from entering the access network PCN-domain) and
so on. It is not done at the PCN-ingress-node. Note:
to aid readability, the rest of this draft assumes generally required that policing
is done by the PCN-ingress-nodes.

o Pseudowire: PCN other network entities
are aware of individual flows (although they may be used as a congestion avoidance mechanism
for edge to edge pseudowire emulations
[I-D.ietf-pwe3-congestion-frmwk]. in particular
deployment scenarios).

o MPLS: [RFC3270] defines how to support Admission control is resilient: PCN's QoS is decoupled from the DiffServ architecture
routing system; hence in MPLS networks. [RFC5129] describes how general admitted flows can survive
capacity, routing or topology changes without additional
signalling, and they don't have to add PCN for
admission control of microflows into be told (or learn) about such
changes. The PCN-threshold-rate on each PCN-node can be chosen
small enough that admitted traffic can still be carried after a set of MPLS aggregates
(Multi-protocol label switching). PCN-marking
rerouting in most failure cases [Menth]. This is done an important
feature as QoS violations in MPLS's
EXP field.

o Similarly, it may be possible core networks due to extend PCN into Ethernet
networks, where link failures
are more likely than QoS violations due to increased traffic
volume [Iyer].

o The PCN-marking is done in behaviours only operate on the Ethernet header. NOTE:
Specific consideration overall PCN-traffic
on the link, not per flow.

o The information of this extension these measurements is outside signalled to the IETF's
remit.

From PCN-
egress-nodes by the perspective of PCN-marks in the outside world, a PCN-domain essentially
looks like a DiffServ domain. PCN-traffic packet headers, ie "in-band".
No additional signalling protocol is either transported
across it transparently or policed at required for transporting the PCN-ingress-node (ie
dropped or carried at a lower QoS). A couple of differences are
that:
PCN-marks. Therefore no secure binding is required between data
packets and separate congestion messages.

o The PCN-egress-nodes make separate measurements, operating on the
aggregate PCN-traffic has better QoS guarantees than normal DiffServ
traffic (because PCN's mechanisms better protect from each PCN-ingress-node, ie not per flow.
Similarly, signalling by the QoS PCN-egress-node of admitted
flows); PCN-feedback-
information (which is used for flow admission and in rare circumstances (failures), on the one hand some
PCN-flows may get terminated, but on the other hand other flows will
get their QoS restored. Non PCN-traffic termination
decisions) is treated transparently, ie at the PCN-domain is a normal DiffServ domain.

2. Terminology

o PCN-domain: a PCN-capable domain; a contiguous set granularity of PCN-enabled
nodes the ingress-egress-aggregate.
An alternative approach is that perform DiffServ scheduling; the compete set of PCN-
nodes whose PCN-marking can in principle influence decisions about PCN-egress-nodes monitor the
PCN-traffic and signal PCN-feedback-information (which is used for
flow admission and termination for the PCN-domain, including decisions) at the
PCN-egress-nodes which measure these PCN-marks.

o PCN-boundary-node: a PCN-node that connects granularity of
one PCN-domain to a
node either in another PCN-domain or in (or a non PCN-domain. few) PCN-marks.

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

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

Eardley (Editor) Expires August 11, 2008 [Page 7]

Internet-Draft Document February 2008

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

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

o PCN-traffic: A PCN-domain carries traffic of different DiffServ
behaviour aggregates [RFC2475]. Those using the PCN mechanisms
are called PCN-BAs (collectively called PCN-traffic) traffic matrix changes, and also if the
corresponding packets are PCN-packets. The same network may carry
traffic using other DiffServ BAs. A PCN-flow is the unit of PCN-
traffic that the PCN-boundary-node admits (or terminates); the
unit could be
topology changes (eg after a single microflow (as defined link failure). Hence an operator can
be less conservative when deploying network capacity, and less
accurate in [RFC2475]) or some
identifiable collection their prediction of microflows. the PCN-traffic matrix.

o Ingress-egress-aggregate: The collection of PCN-packets termination mechanism complements admission control. It
allows the network to recover from all
PCN-flows sudden unexpected surges of
PCN-traffic on some links, thus restoring QoS to the remaining
flows. Such scenarios are expected to be rare but not impossible.
They can be caused by large network failures that travel in one direction between a specific pair redirect lots of
admitted PCN-traffic to other links, or by malfunction of
PCN-boundary-nodes.

o PCN-lower-rate: a reference rate configured for each link in the
PCN-domain, which is lower than
measurement-based admission control in the PCN-upper-rate. It is used by
a marking behaviour presence of admitted

Eardley (Editor) Expires January 15, 2009 [Page 7]

Internet-Draft Document July 2008

flows that determines whether send for a packet should be
PCN-marked while with an atypically low rate and then
increase their rates in a first encoding. correlated way.

o PCN-upper-rate: a reference rate configured for each link Flow termination can also enable an operator to be less
conservative when deploying network capacity. It is an
alternative to running links at low utilisation in the
PCN-domain, which order to
protect against link or node failures. This is higher than especially the PCN-lower-rate. It is used
by a marking behaviour that determines whether a packet should be
PCN-marked
case with SRLGs (shared risk link groups, which are links that
share a second encoding.

o Threshold-marking: a PCN-marking behaviour resource, such that all PCN-
traffic is marked if the PCN-traffic exceeds a particular rate
(either the PCN-lower-rate or PCN-upper-rate). NOTE: The
definition reflects the overall intent rather than its
instantaneous behaviour, since the rate measured at a particular
moment depends on the behaviour, its implementation and the
traffic's variance as well as its rate.

o Excess-rate-marking: a PCN-marking behaviour such that the amount
of PCN-traffic that is PCN-marked is equal fibre, whose failure affects all those
links [RFC4216]. A requirement to the amount that
exceeds fully protect traffic against a particular rate (either
single SRLG failure requires low utilisation (~10%) of the PCN-lower-rate or PCN-upper-
rate). NOTE: link
bandwidth on some links before failure [PCN-email-SRLG].

o The definition reflects the overall intent rather
than its instantaneous behaviour, since PCN-excess-rate may be set below the maximum rate measured at a
particular moment depends that PCN-
traffic can be transmitted on the behaviour, its implementation and
the traffic's variance as well as its rate.

o Pre-congestion: a condition of a link within a PCN-domain in which
the PCN-node performs PCN-marking, link, in order to provide an "early
warning" trigger
termination of potential congestion some PCN-flows before there is any significant

Eardley (Editor) Expires August 11, 2008 [Page 8]

Internet-Draft Document February 2008

build-up loss (or excessive delay) of
PCN-packets in occurs, or to keep the real queue. (Hence, maximum PCN-load on a link
below a level configured by analogy
with ECN we call our mechanism Pre-Congestion Notification.) the operator.

o PCN-marking: Provisioning of the network is decoupled from the process of setting
adding new customers. By contrast, with the header in a PCN-packet
based DiffServ architecture
[RFC2475] operators rely on defined rules, in reaction to pre-congestion.

o PCN-feedback-information: information signalled by a PCN-egress-
node to a PCN-ingress-node or central control node, which is
needed for subscription-time Service Level
Agreements that statically define the flow admission and flow termination mechanisms.

3. Assumptions and constraints on scope

The scope parameters of PCN is, at least initially (see Appendix A), restricted
by the following assumptions:

1. these components are deployed in traffic
that will be accepted from a single DiffServ domain, within
which all PCN-nodes are PCN-enabled and trust each other for
truthful PCN-marking and transport

2. all flows handled by these mechanisms are inelastic customer, and
constrained so the operator has to a known peak rate through policing or shaping

3.
run the number of PCN-flows across any potential bottleneck link provisioning process each time a new customer is
sufficiently large added to
check that stateless, statistical mechanisms the Service Level Agreement can be
effective. To put it another way, the aggregate bit rate of fulfilled. A PCN-
domain doesn't need such traffic across any potential bottleneck link needs to be
sufficiently large relative to the maximum additional bit rate
added by one flow. This is the basic assumption of measurement-
based admission control. conditioning.

4. PCN-flows may have different precedence, but the applicability Deployment scenarios

Operators of networks will want to use the PCN mechanisms in various
arrangements, for emergency use (911, GETS, WPS, MLPP, etc.)
is out of scope.

3.1. Assumption 1: Trust and support of PCN - controlled environment

We assume that instance depending on how they are performing
admission control outside the PCN-domain is a controlled environment, i.e. (users after all are
concerned about QoS end-to-end), what their particular goals and
assumptions are, how many PCN encoding states are available, and so
on.

From the nodes in perspective of the outside world, a PCN-domain run PCN and trust each other. There are
several reasons for proposing this assumption:

o The PCN-domain has to be encircled by essentially
looks like a ring DiffServ domain. PCN-traffic is either transported
across it transparently or policed at the PCN-ingress-node (ie
dropped or carried at a lower QoS). A couple of PCN-boundary-
nodes, otherwise differences are
that: PCN-traffic has better QoS guarantees than normal DiffServ
traffic could enter a PCN BA without being
subject to admission control, which would potentially degrade (because PCN's mechanisms better protect the QoS of existing PCN-flows.

o Similarly, a PCN-boundary-node has to trust that all admitted
flows); and in rare circumstances (failures), on the PCN-nodes
mark one hand some
PCN-flows may get terminated, but on the other hand other flows will
get their QoS restored. Non PCN-traffic consistently. A node not doing PCN-marking is treated transparently, ie
the PCN-domain is a normal DiffServ domain.

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 9] 8]

Internet-Draft Document February July 2008

wouldn't be able

An operator may choose to alert when it suffered pre-congestion, which
potentially would lead deploy either admission control or flow
termination or both. Although designed to too many PCN-flows being admitted (or
too few being terminated). Worse, a rogue node could perform
various attacks, as discussed in work together, they are
independent mechanisms, and the Security Considerations
section.

One way use of assuring one does not require or
prevent the above two points is that use of the entire PCN-
domain is run other.

For example, an operator could use just PCN's admission control,
solving heavy congestion (caused by a single operator. Another possibility is that
there are several operators but they trust each other re-routing) by 'just waiting' -
as sessions end, PCN-traffic naturally reduces, and meanwhile the
admission control mechanism will prevent admission of new flows that
use the affected links. So the PCN-domain will naturally return to a sufficient
level, in their handling
normal operation, but with reduced capacity. The drawback of PCN-traffic.

Note: All PCN-nodes need this
approach would be that until PCN-traffic naturally departs to relieve
the congestion, all PCN-flows as well as lower priority services will
be trustworthy. However if it's known adversely affected.

Another example is that an interface cannot become pre-congested then it's not strictly
necessary operator could just rely for it to be capable admission
control on statically provisioned capacity per PCN-ingress-node
(regardless of PCN-marking. But this must be
known even in unusual circumstances, eg after the failure of some
links.

3.2. Assumption 2: Real-time applications

We assume that any variation PCN-egress-node of source bit rate a flow), as is independent of typical in the
level
hose model of pre-congestion. We assume that PCN-packets come from real
time applications generating inelastic traffic [Shenker] like voice
and video requiring low delay, jitter and packet loss, for example
the Controlled Load Service, [RFC2211], and the Telephony service
class, [RFC4594]. This assumption is DiffServ architecture [RFC2475]. Such traffic
conditioning agreements can lead to focused overload: many flows
happen to help focus on a particular link and then all flows through the effort where
it looks like PCN would
congested link fail catastrophically. PCN's flow termination
mechanism could then be most useful, ie the sorts used to counteract such a problem.

The possibility of applications
where per deploying just one of PCN's flow QoS admission and
termination mechanisms is a known requirement. In other words we focus
on certainly an option when only two PCN providing a benefit to inelastic traffic (PCN may or may
encoding states are available (PCN-marked and not
provide a benefit to other types of traffic). For instance, the
impact of PCN-marked), as in
[I-D.moncaster-pcn-baseline-encoding]. Another option in this assumption would be
circumstance is to guide simulations work.

3.3. Assumption 3: Many flows trigger both admission control and additional load

We assume that there are many PCN-flows on any bottleneck link in the
PCN-domain (or, to put it another way, flow
termination from the aggregate bit rate single type of PCN-
traffic across any potential bottleneck link is sufficiently large
relative to PCN-marking; the maximum additional bit rate added by one PCN-flow).
Measurement-based main downside is
that admission control assumes that is less accurate.

Within the present PCN-domain there is a
reasonable prediction of some flexibility about where the future:
decision making functionality is located. For admission control, the network conditions are
measured at
most natural place is the time of a new PCN-ingress-node. For flow request, however termination,
whether the actual
network performance must be OK during PCN-ingress-node or PCN-egress-node is more natural
depends on the call some time later. One
issue mechanism used to convert packet markings into a flow
termination decision. These possibilities are outlined more later
and also discussed elsewhere, such as in [Menth08]. Another
possibility is that if there are only a few variable rate flows, then the
aggregate traffic level may vary a lot, perhaps enough to cause decision making functionality is at some
packets
central control node. This is briefly discussed in Appendix A and
described in [I-D.tsou-pcn-racf-applic].

The flow admission and termination decisions need to get dropped. be enforced
through per-flow policing by the PCN-ingress-nodes. If there are many flows then the aggregate
traffic level should be statistically smoothed. How many flows is
enough depends
several PCN-domains on a number of things such as the variation in end-to-end path then each
flow's rate, the total rate of PCN-traffic, and needs to police
at its PCN-ingress-nodes. One exception is if the size of operator runs both
the
"safety margin" between access network (not a PCN-domain) and the traffic level at which we start core network (a PCN-

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 10] 9]

Internet-Draft Document February July 2008

admission-marking

domain); per flow policing could be devolved to the access network
and at which packets are dropped or significantly
delayed.

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

3.4. Assumption 4: Emergency use out of scope

PCN-flows may have different precedence, but PCN-ingress-node. Note: to aid readability, the applicability
rest of the
PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc) this draft assumes that policing is out
of scope for consideration done by the PCN-ingress-
nodes.

PCN WG.

3.5. Other assumptions

As a consequence of Assumption 2 above, it is assumed that PCN-
marking is being applied admission control has to traffic scheduled with the expedited
forwarding per-hop behaviour, [RFC3246], or traffic fit with similar
characteristics.

The following two assumptions apply if the PCN WG decides overall approach to encode
PCN-marking in
admission control. For instance [I-D.briscoe-tsvwg-cl-architecture]
describes the ECN-field.

o It is assumed that PCN-nodes do not perform ECN, [RFC3168], on
PCN-packets.

o What to do if a packet that case where RSVP signalling runs end-to-end. The PCN-
domain is part of a PCN-flow arrives at a
PCN-ingress-node single RSVP hop, ie only the PCN-boundary-nodes process
RSVP messages, with its CE (Congestion experienced) codepoint
set (or if it detects that RSVP messages processed on each hop outside the ECN-nonce in use). There are
several possibilities (not discussed further
PCN-domain, as in this document)
about what IntServ over DiffServ [RFC2998]. It would also be
possible for the PCN-ingress-node should do:

* drop RSVP signalling to be originated and/or terminated
by proxies, with application-layer signalling between the packet

* downgrade end user
and the packet proxy (eg SIP signalling with a home hub). A similar example
would use NSIS signalling is used instead of RSVP.

It is possible that a user wants its inelastic traffic to use the PCN
mechanisms but also react to ECN marking outside the PCN-domain
[I-D.sarker-pcn-ecn-pcn-usecases]. Two ways to do this are to non PCN-BA, eg best effort

* tunnel
all PCN-packets across the packet, PCN-domain, so that the ECN-marking ECN marks is
carried transparently across the PCN-domain.

4. High-level functional architecture

The high-level approach is PCN-domain, or to split functionality between:

o PCN-interior-nodes 'inside' use the PCN-domain, which monitor their
own three
state of pre-congestion on each outgoing interface and mark
PCN-packets if appropriate. They are not flow-aware, nor aware of

Eardley (Editor) Expires August 11, 2008 [Page 11]

Internet-Draft Document February 2008

ingress-egress-aggregates. The functionality is also done by PCN-
ingress-nodes for 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 information from PCN-interior-nodes. PCN encoding [I-D.moncaster-pcn-3-state-encoding]. This information is
discussed further in the form of the PCN-marked data packets (which Section Section 7.

Some possible deployment models that are intercepted
by outside the PCN-egress-nodes) and not signalling messages. Generally
PCN-ingress-nodes current PCN WG
Charter are flow-aware. outlined in Appendix A.

5. Assumptions and constraints on scope

The aim of this split is to keep the bulk scope of PCN is, at least initially (see Appendix A), restricted
by the network simple,
scalable following assumptions:

1. these components are deployed in a single DiffServ domain, within
which all PCN-nodes are PCN-enabled and robust, whilst confining policy, application-level trust each other for
truthful PCN-marking and
security interactions transport

2. all flows handled by these mechanisms are inelastic and
constrained to a known peak rate through policing or shaping

3. the edge of the PCN-domain. For example the
lack number of flow awareness means that the PCN-interior-nodes don't care
about the flow information associated with the PCN-packets that they
carry, nor do the PCN-boundary-nodes care about which PCN-interior-
nodes its flows traverse.

The objective PCN-flows across any potential bottleneck link is to standardise PCN-marking behaviour, but
potentially produce more than one (informational) RFC describing how
PCN-boundary-nodes react to PCN-marks.

Note: Section 4 and Section 5 talk about PCN functionality being
configured on outgoing interfaces of PCN-nodes. Alternatively, PCN
functionality could
sufficiently large that stateless, statistical mechanisms can be configured on
effective. To put it another way, the ingress interfaces aggregate bit rate of PCN-
nodes, however a consistent choice must be made
traffic across the PCN-domain any potential bottleneck link needs to be
sufficiently large relative to ensure that the PCN mechanisms protect all links. maximum additional bit rate
added by one flow. This document
assumes configuration on the egress interfaces, because in DiffServ
networks today DiffServ functionality is usually implemented on
egress interfaces.

4.1. Flow the basic assumption of measurement-
based admission

At a high level, flow admission control works as follows. In order
to generate information about control.

Eardley (Editor) Expires January 15, 2009 [Page 10]

Internet-Draft Document July 2008

4. PCN-flows may have different precedence, but the current state applicability of
the PCN-domain,
each PCN-node PCN-marks packets if it is "pre-congested". Exactly
how a PCN-node decides if it is "pre-congested" (the algorithm) and
exactly how packets are "PCN-marked" (the encoding) will be defined
in a separate standards-track document, but at a high level it PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.)
is
expected to be as follows:

o the algorithm: a PCN-node meters the amount out of PCN-traffic on each
one scope.

5.1. Assumption 1: Trust and support of its outgoing links. The measurement PCN - controlled environment

We assume that the PCN-domain is made as an
aggregate of a controlled environment, ie all PCN-packets, the
nodes in a PCN-domain run PCN and not per flow. trust each other. There are
several reasons for proposing this assumption:

o The algorithm PCN-domain has to be encircled by a configured parameter, PCN-lower-rate. As the amount ring of PCN- PCN-boundary-
nodes, otherwise traffic exceeds could enter a PCN BA without being
subject to admission control, which would potentially degrade the PCN-lower-rate, then PCN-packets are PCN-
marked. See NOTE below for more explanation.

Eardley (Editor) Expires August 11, 2008 [Page 12]

Internet-Draft Document February 2008
QoS of existing PCN-flows.

o the encoding: a PCN-node PCN-marks a PCN-packet (with Similarly, a first
encoding) by setting fields in the header PCN-boundary-node has to specific values. It
is expected trust that all the ECN and/or DSCP fields will PCN-nodes
mark PCN-traffic consistently. A node not doing PCN-marking
wouldn't be used.

NOTE: Two main categories of algorithm have been proposed: if the
algorithm uses threshold-marking then all PCN-packets are marked if
the current rate exceeds the PCN-lower-rate, whereas if the algorithm
uses excess-rate-marking the amount marked is equal able to the amount in
excess of the PCN-lower-rate. However, note that this description
reflects the overall intent of the algorithm rather than its
instantaneous behaviour, since the rate measured at alert when it suffered pre-congestion, which
potentially would lead to too many PCN-flows being admitted (or
too few being terminated). Worse, a particular
moment depends on the detailed algorithm, its implementation and the
traffic's variance as well rogue node could perform
various attacks, as its rate (eg marking may well continue
after a recent overload even after the instantaneous rate has
dropped).

The PCN-boundary-nodes monitor the PCN-marked packets discussed in order to
extract information about the current state Security Considerations
section.

One way of assuring the PCN-domain. Based
on this monitoring, a decision above two points is made about whether to admit a
prospective new flow. Exactly how that the admission control decision entire PCN-
domain is
made will be defined separately (at the moment the intention run by a single operator. Another possibility is that
there will be one or more informational-track RFCs), are several operators but at a high
level two approaches have been proposed they trust each other to date:

o the PCN-egress-node measures (possibly as a moving average) the
fraction sufficient
level, in their handling of the PCN-traffic PCN-traffic.

Note: All PCN-nodes need to be trustworthy. However if it's known
that is PCN-marked. The fraction is
measured for a specific ingress-egress-aggregate. If the fraction
is below a threshold value an interface cannot become pre-congested then the new flow is admitted.

o if the PCN-egress-node receives one (or several) PCN-marked
packets, then a new flow is blocked, otherwise it's not strictly
necessary for it is admitted.

Note that the PCN-lower-rate is a parameter that can to be configured by
the operator. It will capable of PCN-marking. But this must be set lower than
known even in unusual circumstances, eg after the traffic failure of some
links.

5.2. Assumption 2: Real-time applications

We assume that any variation of source bit rate is independent of the
level of pre-congestion. We assume that PCN-packets come from real
time applications generating inelastic traffic, ie it sends packets
at which the link becomes congested and rate the node drops packets.

Note also that codec produces them, regardless of the admission control decision is made for a
particular pair availability
of PCN-boundary-nodes. So it capacity [RFC4594]. For example, voice and video requiring low
delay, jitter and packet loss, the Controlled Load Service,
[RFC2211], and the Telephony service class, [RFC4594]. This
assumption is quite possible for a
new flow to help focus the effort where it looks like PCN would
be admitted between one pair of PCN-boundary-nodes,
whilst at most useful, ie the same time another admission request sorts of applications where per flow QoS is blocked between a different pair of PCN-boundary-nodes.

4.2. Flow termination

At
known requirement. In other words we focus on PCN providing a high level, flow termination control works as follows. Each
PCN-node PCN-marks packets in
benefit to inelastic traffic (PCN may or may not provide a similar fashion benefit to above, with all
proposals using an excess-rate-marking approach (Section 4.1). An
obvious approach is for
other types of traffic). For instance, the algorithm to use a second configured impact of this assumption

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 13] 11]

Internet-Draft Document February July 2008

parameter, PCN-upper-rate, and

would be to guide simulations work.

As a second header encoding. However
there consequence, it is also a proposal assumed that PCN-marking is being applied to use
traffic scheduled with the same rate expedited forwarding per-hop behaviour,
[RFC3246], or traffic with similar characteristics.

5.3. Assumption 3: Many flows and the same encoding.
Several approaches have been proposed to date about how to convert
this information into a flow termination decision; at a high level
these additional load

We assume that there are as follows:

o In one approach many PCN-flows on any bottleneck link in the PCN-egress-node measures
PCN-domain (or, to put it another way, the aggregate bit rate of unmarked
PCN-traffic (ie not PCN-upper-rate-marked), which PCN-
traffic across any potential bottleneck link is sufficiently large
relative to the amount of
PCN-traffic maximum additional bit rate added by one PCN-flow).
Measurement-based admission control assumes that can actually be supported. Also the PCN-ingress-
node measures present is a
reasonable prediction of the rate future: the network conditions are
measured at the time of PCN-traffic that is destined for this
specific PCN-egress-node, and hence can calculate a new flow request, however the excess
amount that should actual
network performance must be terminated.

o Another approach instead measures OK during the call some time later. One
issue is that if there are only a few variable rate of PCN-upper-rate-
marked traffic and calculates and selects flows, then the
aggregate traffic level may vary a lot, perhaps enough to cause some
packets to get dropped. If there are many flows that then the aggregate
traffic level should be
terminated.

o Another approach terminates any PCN-flow with statistically smoothed. How many flows is
enough depends on a PCN-upper-rate-
marked packet. Compared with number of things such as the approaches above, PCN-marking
needs to be done at a reduced variation in each
flow's rate, the total rate (every "s" bytes of excess
traffic) otherwise far too much traffic would be terminated.

o Another approach uses only one sort PCN-traffic, and the size of marking, which is based on the PCN-lower-rate, to decide
"safety margin" between the traffic level at which we start
admission-marking and at which packets are dropped or significantly
delayed.

We do not only make explicit assumptions on how many PCN-flows are in each
ingress-egress-aggregate. Performance evaluation work may clarify
whether it is necessary to admit more PCN-
flows but also whether make any PCN-flows need to be terminated. It
assumes that additional assumption on
aggregation at the ratio ingress-egress-aggregate level.

5.4. Assumption 4: Emergency use out of scope

PCN-flows may have different precedence, but the (implicit) PCN-upper-rate and applicability of the
PCN-lower-rate
PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc) is the same on all links. This approach measures
the rate out
of unmarked PCN-traffic at a PCN-egress-node. scope for consideration by the PCN WG.

6. High-level functional architecture

The PCN-
ingress-node uses this measurement high-level approach is to compute split functionality between:

o PCN-interior-nodes 'inside' the implicit PCN-
upper-rate PCN-domain, which monitor their
own state of the bottleneck link. It then measures the rate pre-congestion and mark PCN-packets if appropriate.
They are not flow-aware, nor aware of
PCN-traffic that ingress-egress-aggregates.
The functionality is destined also done by PCN-ingress-nodes for this specific PCN-egress-node and
hence can calculate their
outgoing interfaces (ie those 'inside' the amount that should be terminated.

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 bear this in mind.

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

4.3. Flow admission and flow termination

Although designed to work together, flow admission and flow
termination are independent mechanisms, and the use of one does not PCN-domain).

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 14] 12]

Internet-Draft Document February July 2008

require or prevent

o PCN-boundary-nodes at the use edge of the other.

For example, an operator could use just PCN-domain, which control
admission control, solving
heavy congestion (caused by re-routing) by 'just waiting' - as
sessions end, of new PCN-flows and termination of existing microflows naturally depart PCN-flows,
based on information from PCN-interior-nodes. This information is
in the system
over time, and the admission control mechanism will prevent admission form of new microflows that use the affected links. So PCN-marked data packets (which are intercepted
by the PCN-domain
will naturally return to normal operation, but with reduced capacity. PCN-egress-nodes) and not signalling messages. Generally
PCN-ingress-nodes are flow-aware.

The drawback aim of this approach would be that until PCN-flows naturally
depart split is to relieve the congestion, all PCN-flows as well as lower
priority services will be adversely affected. On keep the other hand, an
operator could just rely for admission control on statically
provisioned capacity per PCN-ingress-node (regardless bulk of the PCN-
egress-node of a flow), as is typical in network simple,
scalable and robust, whilst confining policy, application-level and
security interactions to the hose model edge of the
DiffServ architecture [RFC2475]. Such traffic conditioning
agreements can lead to focused overload: many flows happen to focus
on a particular link and then all flows through PCN-domain. For example the congested link
fail catastrophically. The
lack of flow termination mechanism could then be
used to counteract such a problem.

A different possibility is to configure only awareness means that the PCN-interior-nodes don't care
about the PCN-lower-rate and
hence only do one type of PCN-marking, but generate admission and flow termination responses from different levels of marking. This is
suggested in [I-D.charny-pcn-single-marking] which gives some of information associated with the
pros and cons of this approach.

4.4. Information transport PCN-packets that they
carry, nor do the PCN-boundary-nodes care about which PCN-interior-
nodes its flows traverse. The transport of pre-congestion information from a PCN-node to a PCN-
egress-node is through PCN-markings in data packet headers, ie "in-
band": no signalling protocol messaging is needed. However,
signalling objective is needed to transport PCN-feedback-information between
the PCN-boundary-nodes, for example standardise PCN-
marking behaviour, but potentially produce more than one
(informational) RFC describing how PCN-boundary-nodes react to convey the fraction of PCN-
marked traffic from a PCN-egress-node
marks.

In order to the relevant PCN-ingress-
node. Exactly what generate information needs to be transported will be
described in the future PCN WG document(s) about the boundary
mechanisms. The signalling could be done by an extension current state of RSVP or
NSIS, for instance; protocol work will be done by the relevant WG,
but for example [I-D.lefaucheur-rsvp-ecn] describes the extensions
needed for RSVP.

4.5. PCN-traffic

The following are some high-level points about PCN-
domain, each PCN-node PCN-marks packets if it is "pre-congested".
Exactly when a PCN-node decides if it is "pre-congested" (the
algorithm) and exactly how PCN works: packets are "PCN-marked" (the encoding)
are defined in separate standards-track documents, but at a high
level it is as follows:

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

o the encoding(s): a PCN-node to distinguish PCN-traffic
from non PCN-traffic. They may be distinguished using PCN-marks a PCN-packet by setting the DSCP
field and/or
ECN field.

Eardley (Editor) Expires August 11, 2008 [Page 15]

Internet-Draft Document February 2008

o field to 11 and potentially altering the DSCP.

The PCN mechanisms may be applied PCN-boundary-nodes monitor the PCN-marked packets in order to more than one behaviour
aggregate (which are distinguished by DSCP).

o There may be traffic that
extract information about the current state of the PCN-domain. Based
on this monitoring, a decision is more important than PCN, perhaps made about whether to admit a
particular application
prospective new flow or an operator's control messages. A PCN-
node may dedicate capacity whether to such traffic or priority schedule it
over PCN. In the latter case its traffic terminate existing flow(s).

PCN-marking needs to contribute be configured on all links in the PCN-domain to
ensure that the PCN meters.

o There will mechanisms protect all links. The actual
functionality can be traffic less important than PCN. For instance best
effort configured on the outgoing or assured forwarding traffic. It will be scheduled at
lower priority than PCN, and use a separate queue incoming
interfaces of PCN-nodes - or queues.
However, a PCN-node should dedicate some capacity to lower
priority traffic so that it isn't starved.

o There may one algorithm could be configured on the
outgoing interface and the other traffic with on the same priority as PCN-traffic.
For instance, Expedited Forwarding sessions incoming interface. The
important thing is that are originated
either without capacity admission or with traffic engineering. In
[I-D.ietf-tsvwg-admitted-realtime-dscp] the two traffic classes
are called EF and EF-ADMIT. A PCN-node could either use separate
queues, or separate policers and a common queue; the draft
provides some guidance when each consistent choice is better, but made across the PCN-
domain to ensure that the PCN mechanisms protect all links. See
[I-D.eardley-pcn-marking-behaviour] for instance further discussion.

Eardley (Editor) Expires January 15, 2009 [Page 13]

Internet-Draft Document July 2008

The objective of the
latter threshold-marking algorithm is preferred when to threshold-mark
all PCN-packets whenever the two traffic classes are carrying rate of PCN-packets is greater than some
configured rate, the
same type PCN-threshold-rate. The objective of application with the same jitter requirements.

5. Detailed Functional architecture

This section
excess-traffic-marking algorithm is intended to provide excess-traffic-mark PCN-
packets at a systematic summary rate equal to the difference between the bit rate of
PCN-packets and some configured rate, the new
functional architecture in PCN-excess-rate. Note that
this description reflects the PCN-domain. First it describes
functions needed overall intent of the algorithm rather
than its instantaneous behaviour, since the rate measured at a
particular moment depends on the three specific types of PCN-node; these are
data plane functions detailed algorithm, its
implementation and are in addition to their normal router
functions. Then it describes further functionality needed for both
flow admission control and flow termination; these are signalling and
decision-making functions, and there are various possibilities for
where the functions are physically located. traffic's variance as well as its rate (eg
marking may well continue after a recent overload even after the
instantaneous rate has dropped). The 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

Eardley (Editor) Expires August 11, 2008 [Page 16]

Internet-Draft Document February 2008

Note: Probing is covered algorithms are specified in Section 7.

The section then discusses some other detailed topics:

1. addressing

2. tunnelling

3. fault handling

5.1. PCN-interior-node functions

Each interface of the
[I-D.eardley-pcn-marking-behaviour].

In a PCN-domain is configured with the following
functionality:

o Packet classify - decide whether an incoming packet operator may have two or three encoding states
available. In both cases the ECN field is a set to 11 to indicate PCN-
packet or not. Another PCN WG document will specify encoding,
using
marking. In the former case, one DSCP and/or ECN fields.

o PCN-meter - measure is used. In the 'amount of PCN-traffic'. The measurement latter case a
second DSCP is made as an aggregate of all PCN-packets, and not per flow.

o PCN-mark - algorithms determine whether to PCN-mark PCN-packets used, which allows distinct threshold-marks and what packet
excess-traffic-marks. The encoding is used (as specified in another PCN WG
document).

The same general approach of metering and PCN-marking is performed
for both flow admission control
[I-D.moncaster-pcn-baseline-encoding] and flow termination, however
[I-D.moncaster-pcn-3-state-encoding].

All the
algorithms various admission and encoding may be different.

These functions termination approaches are needed for each interface of the PCN-domain.
They detailed and
compared in [I-D.charny-pcn-comparison] and [Menth08]. The
discussion below is just a brief summary. It initially assumes there
are therefore needed on all interfaces three encoding states available.

6.1. Flow admission

The objective of PCN-interior-nodes,
and PCN's flow admission control mechanism is to limit
the PCN-traffic on each link in the interfaces PCN-domain to *roughly* its PCN-
threshold-rate, by admitting or blocking prospective new flows, in
order to protect the QoS of PCN-boundary-nodes existing PCN-flows. The PCN-threshold-
rate is a parameter that are internal to can be configured by the
PCN-domain. There may operator and will
be more set lower than one PCN-meter and marker
installed the traffic rate at a given interface, eg one for admission which the link becomes
congested and one for
termination.

5.2. PCN-ingress-node functions

Each ingress interface of the PCN-domain is configured with node drops packets.

Exactly how the
following functionality:

o Packet classify - decide whether an incoming packet admission control decision is part made will be defined
separately in informational documents. At a high level two
approaches are proposed:

o the PCN-egress-node measures (possibly as a moving average) the
fraction of the PCN-traffic that is threshold-marked. The
fraction is measured for a
previously admitted microflow, by using specific ingress-egress-aggregate. If
the fraction is below a filter spec (eg DSCP,
source threshold value then the new flow is
admitted, and destination addresses if the fraction is above the threshold value then it
is blocked. In [I-D.eardley-pcn-architecture] the fraction is
measured as an EWMA (exponentially weighted moving average) and port numbers)

o Police - police, by dropping or re-marking with a non-PCN DSCP,
any packets received with a DSCP demanding PCN transport that do

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 17] 14]

Internet-Draft Document February July 2008

not belong to an admitted flow. Similarly, police packets that
are part of a previously admitted microflow, to check that

termed the
microflow keeps to "congestion level estimate".

o the agreed rate or flowspec (eg RFC1633
[RFC1633] PCN-egress-node monitors PCN-traffic and NSIS equivalent). There if it receives one
(or several) threshold-marked packets, then the new flow is
blocked, otherwise it is admitted. One possibility is a need to be careful react to
avoid re-ordering traffic.

o PCN-colour - set
the DSCP field or DSCP and ECN fields to marking state of an initial flow set-up packet (eg RSVP PATH).
Another is that after one (or several) threshold-marks then all
flows are blocked until after a specific period of no congestion.

Note that the
appropriate value(s) admission control decision is made for a PCN-packet. The draft about PCN-
encoding will discuss further.

o PCN-meter - make "measurements particular
pair of PCN-traffic". Some approaches
to PCN-boundary-nodes. So it is quite possible for a new flow termination require the PCN-ingress-node
to measure the
(aggregate) rate be admitted between one pair of PCN-traffic towards PCN-boundary-nodes, whilst at the
same time another admission request is blocked between a particular PCN-egress-
node. different
pair of PCN-boundary-nodes.

6.2. Flow termination

The first two are policing functions, needed objective of PCN's flow termination mechanism is to make sure that PCN-
packets admitted into limit the PCN-domain belong
PCN-traffic on each link to a flow that's been
admitted and *roughly* its PCN-excess-rate, by
terminating some existing PCN-flows, in order to ensure that protect the flow keeps to QoS of
the flowspec agreed (eg
doesn't go at a faster rate and remaining PCN-flows. The PCN-excess-rate is inelastic traffic). Installing
the filter spec will typically a parameter that can
be done configured by the signalling protocol, as
will re-installing operator and may be set lower than the filter, for example after traffic
rate at which the link becomes congested and the node drops packets.

Exactly how the flow termination decision is made will be defined
separately in informational documents. At a re-route that
changes high level several
approaches are proposed:

o In one approach the PCN-ingress-node (see [I-D.briscoe-tsvwg-cl-architecture]
for an example using RSVP). PCN-colouring allows PCN-egress-node measures the rest rate of PCN-
traffic that is not excess-traffic-marked, which is the
PCN-domain to recognise PCN-packets.

5.3. PCN-egress-node functions

Each egress interface amount of
PCN-traffic that can actually be supported. Also the PCN-domain PCN-ingress-
node measures the rate of PCN-traffic that is configured with destined for this
specific PCN-egress-node, and hence it can calculate the
following functionality:

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

o PCN-meter - "measure PCN-traffic" or "monitor PCN-marks". excess
amount that should be terminated.

o PCN-colour - for PCN-packets, set Another approach instead measures the DSCP rate of excess-traffic-
marked traffic and ECN fields to the
appropriate values for use outside terminates this amount of traffic. This
terminates more traffic than the PCN-domain. previous bullet if some nodes are
dropping PCN-traffic.

o Another PCN WG document, about boundary mechanisms, will describe
PCN-metering in more detail. As described in Section 4.1 approach monitors PCN-packets and Section
4.2, at present there are two alternative proposals: to measure as terminates any PCN-flow
with an
aggregate (ie not per flow) all PCN-packets from a particular PCN-
ingress-node; or to monitor excess-traffic-marked packet. Compared with the PCN-traffic and react to one (or
several) PCN-marks. We refer to these
approaches as "measuring PCN-
traffic" and "monitoring PCN-marks". The PCN-metering functionality
also depends on whether the measurement is targeted above, PCN-marking needs to be done at admission
control or a reduced rate
(every "s" bytes of excess traffic) otherwise far too much traffic
would be terminated.

Since flow termination. It also depends on what encoding and
PCN-marking algorithms termination is designed for "abnormal" circumstances, it
is quite likely that some PCN-nodes are specified by the PCN WG. congested and hence packets

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 18] 15]

Internet-Draft Document February July 2008

5.4. Other admission control functions

As well as

are being dropped and/or significantly queued. The flow termination
mechanism must bear this in mind.

Note also that the functions covered above (Sections 5.1, 5.2, 5.3),
other specific admission termination control functions can decision is made for a
particular pair of PCN-boundary-nodes. So it is quite possible for
PCN-flows to be performed terminated between one pair of PCN-boundary-nodes,
whilst at the same time none are terminated between a PCN-
boundary-node (PCN-ingress-node or PCN-egress-node) or at different pair
of PCN-boundary-nodes.

6.3. Flow admission and flow termination when there are only two PCN
encoding states

If a
centralised node, but PCN-domain has only two encoding states available (PCN-marked
and not at normal PCN-interior-nodes. The
functions are: PCN-marked), ie it's using the baseline encoding
[I-D.moncaster-pcn-baseline-encoding], then an operator has three
options:

o Make decision about admission - based on the output of control only: PCN-marking means threshold-marking, ie
only the PCN-
egress-node's PCN-meter function. In 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 case where it "measures
PCN-traffic", excess-traffic-marking algorithm writes PCN-marks.
Only PCN termination control is available.

o both admission control and flow termination: only the measured traffic on excess-
traffic-marking algorithm writes PCN-marks, however the ingress-egress-aggregate configured
rate (PCN-excess-rate) is compared with some reference level. In set at the case where it
"monitors PCN-marks", then rate the decision is based on whether one
(or several) packets is (are) PCN-marked or not. In either case,
the admission decision also takes account of policy and
application layer requirements.

o Communicate decision about admission - signal the decision control
mechanism needs to the
node making the limit PCN-traffic to.
[I-D.charny-pcn-single-marking] describes how both admission
control request (which may be outside
the PCN-domain), and to the policer (PCN-ingress-node function)
for enforcement of the decision.

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

o The decision is made at the PCN-egress-node triggered in this case and signalled to
also gives some of the
PCN-ingress-node

o pros and cons of this approach. The decision main
downside is made at the PCN-ingress-node, which requires that
the PCN-egress-node signals PCN-feedback-information admission control is less accurate.

6.4. Information transport

The transport of pre-congestion information from a PCN-node to the a PCN-
ingress-node. For example,
egress-node is through PCN-markings in the case where the PCN-meter
function data packet headers, ie "in-
band": no signalling protocol messaging is needed. Signalling is
needed to "measure PCN-traffic" it could signal transport PCN-feedback-information between the PCN-
boundary-nodes, for example to convey the fraction of PCN-traffic that is PCN-marked.

o The decision is made at PCN-marked
traffic from a centralised node (see Appendix).

The decision PCN-egress-node to the relevant PCN-ingress-node.
Exactly what information needs to be passed to transported will be described in
the application layer so that it
can take future PCN WG document(s) about the appropriate action.

5.5. Other flow termination functions

Specific termination control functions can boundary mechanisms. The
signalling could be performed at a PCN-
boundary-node (PCN-ingress-node or PCN-egress-node) done by an extension of RSVP or at a
centralised node, but not at normal PCN-interior-nodes. There are
various possibilities NSIS, for how the functionality can be distributed,
similar to those discussed above in the Admission control section;
the flow termination decision could
instance; protocol work will be made at done by the PCN-ingress-node, relevant WG, but for
example [I-D.lefaucheur-rsvp-ecn] describes the PCN-egress-node or at some centralised node. The functions are: extensions needed for
RSVP.

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 19] 16]

Internet-Draft Document February July 2008

6.5. PCN-traffic

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

o PCN-meter at PCN-egress-node - similarly There needs to flow admission, there
are two proposals: be a way for a PCN-node to "measure PCN-traffic" on distinguish PCN-traffic
from other traffic. This is through a combination of the ingress-egress-
aggregate, and DSCP
field and/or ECN field.

o The PCN mechanisms may be applied to "monitor PCN-marks" more than one behaviour
aggregate which are distinguished by DSCP. However the current
PCN encodings, [I-D.moncaster-pcn-baseline-encoding] and react to
[I-D.moncaster-pcn-3-state-encoding], only allow one (or
several) PCN-marks. PCN-BA.

o (if required) PCN-meter at PCN-ingress-node - make "measurements
of PCN-traffic" being sent towards There may be traffic that is more important than PCN, perhaps a
particular PCN-egress-node;
again, this is done for application or an operator's control messages. A PCN-
node may dedicate capacity to such traffic or priority schedule it
over PCN. In the ingress-egress-aggregate and not per
flow.

o (if required) Communicate PCN-feedback-information latter case its traffic needs to contribute to
the node PCN meters (ie be metered by the threshold-marking and excess-
traffic-marking algorithms).

o There may be other traffic that makes uses the flow termination decision. For example, same DSCP as in
[I-D.briscoe-tsvwg-cl-architecture], communicate PCN-traffic
but with the PCN-egress-
node's measurements ECN field is 00 (Not ECT), and so not subject to the PCN-ingress-node.

o Make decision about PCN-
marking, nor PCN's admission control and flow termination -
mechanisms.. To quote [I-D.moncaster-pcn-baseline-encoding]: "To
conserve DSCPs, DiffServ Codepoints SHOULD be chosen that are
already defined for use with admission controlled traffic, such as
the information from Voice-Admit codepoint defined in [voice-admit]." Since
scheduling behaviour is coupled with the PCN-meter(s) to decide which PCN-flow or PCN-flows to
terminate. The decision takes account of policy and application
layer requirements.

o Communicate decision about flow termination - signal DSCP only, therefore the decision
same scheduling and buffer management rules are applied to non-
PCN-traffic and PCN-traffic using the node that same PCN-enabled DSCP.
There may be no "non-PCN-traffic", but if there is able it needs to
contribute to terminate the flow (which may PCN meters.

o There will be
outside the PCN-domain), traffic less important than PCN. For instance best
effort or assured forwarding traffic. It will be scheduled at
lower priority than PCN, and use a separate queue or queues.
However, a PCN-node should dedicate some capacity to lower
priority traffic so that it isn't starved. Such traffic doesn't
contribute to the policer (PCN-ingress-node
function) PCN meters.

6.6. Backwards compatibility

PCN specifies semantics for enforcement of the decision.

5.6. Addressing

PCN-nodes may need to know the address of other PCN-nodes. Note: in
all cases PCN-interior-nodes don't need to know ECN field that differ from the address
default semantics of any
other PCN-nodes (except as normal their next hop neighbours, [RFC3168]. BCP124 [RFC4774] gives guidelines
for specifying alternative semantics for
routing purposes).

The PCN-egress-node needs to know the address of ECN field. These are
discussed in the PCN-ingress-node
associated with a flow, at baseline encoding
[I-D.moncaster-pcn-baseline-encoding] and extended encoding
[I-D.moncaster-pcn-3-state-encoding] documents. In summary, PCN

Eardley (Editor) Expires January 15, 2009 [Page 17]

Internet-Draft Document July 2008

meets these guidelines by:

o using a minimum so that DSCP (or two DSCPs in the PCN-ingress-node can
be informed extended encoding) to enforce allow PCN-
nodes to distinguish PCN-traffic that uses the admission decision (and any flow
termination decision) through policing. There are various
possibilities alternative ECN
semantics;

o defining these semantics for how use within a controlled region, the PCN-egress-node
PCN-domain;

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

The 'appropriate action' can do this, ie associate differ in the received packet to case of baseline encoding
and extended encoding. In the correct ingress-egress-aggregate. It former, ECN-capable traffic that uses
the same DSCP as PCN is
not blocked from entering the intention of this document PCN-domain
directly. Blocking means it is dropped or downgraded to mandate a particular mechanism.

o The addressing information can lower
priority behaviour aggregate, or alternatively such traffic may be gathered from signalling. For
example, regular processing of an RSVP Path message, as
tunnelled through the PCN-
ingress-node PCN-domain. The reason that blocking is needed
is the previous RSVP hop (PHOP)
([I-D.lefaucheur-rsvp-ecn]).

o Use a probe packet that includes as payload the address PCN-egress-node clears the ECN field to 00. The extended
encoding adds support for end-to-end ECN, since the value of the
PCN-ingress-node.

Eardley (Editor) Expires August 11, 2008 [Page 20]

Internet-Draft Document February 2008

o Always tunnel PCN-traffic ECN
field is preserved across the PCN-domain. Then However, PCN-packets that
get PCN-marked emerge from the PCN-
ingress-node's address is simply PCN-domain with the source address of ECN field set to
11 (CE). It may make sense to expose such marks to a rate adaptive
endpoint. However, it could violate [RFC4774] if the outer
packet header. The PCN-ingress-node endpoint
doesn't understand ECN, and therefore the PCN-domain first needs to learn
ensure that the address end-to-end transport is ECN capable (probably through
signalling).

7. Detailed Functional architecture

This section is intended to provide a systematic summary of the PCN-egress-node, either by manual configuration or by one of
the automated tunnel endpoint discovery mechanisms (such as
signalling or probing over new
functional architecture in the data route, interrogating routing
or using a centralised broker).

5.7. Tunnelling

Tunnels may originate and/or terminate within a PCN-domain. It is
important that First it describes
functions needed at the PCN-marking three specific types of any packet can potentially
influence PCN's PCN-node; these are
data plane functions and are in addition to their normal router
functions. Then it describes further functionality needed for both
flow admission control and termination - it shouldn't
matter whether flow termination; these are signalling and
decision-making functions, and there are various possibilities for
where the packet happens to be tunnelled functions are physically located. The section is split
into:

1. functions needed at the PCN-node
that PCN-marks the packet, or indeed whether it's decapsulated or
encapsulated by a subsequent PCN-node. This suggests that the
"uniform conceptual model" described in [RFC2983] should be re-
applied PCN-interior-nodes

2. functions needed at PCN-ingress-nodes

3. functions needed at PCN-egress-nodes

Eardley (Editor) Expires January 15, 2009 [Page 18]

Internet-Draft Document July 2008

4. other functions needed for flow admission control

5. other functions needed for flow termination control

Note: Probing is covered in Appendix B.

The section then discusses some other detailed topics:

1. addressing

2. tunnelling

3. fault handling

7.1. PCN-interior-node functions

Each link of the PCN context. In line PCN-domain is configured with this and the approach of
[RFC4303] and [I-D.briscoe-tsvwg-ecn-tunnel], the following rule
functionality:

o Packet classify - decide whether an incoming packet is
applied a PCN-
packet or not.

o Packet condition - if encapsulation is done within the PCN-domain:

o any PCN-marking is copied into the outer header

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

o if sufficiently high to
overload the outer header's marking state is more severe PCN_BA, ie cause real congestion, then it is
copied onto the inner header drop or
downgrade PCN-packets.

o Note: Meter - measure the order 'amount of increasing severity is: unmarked; PCN-marking
with first encoding (ie associated with the PCN-lower-rate); PCN-
marking with second encoding (ie associated with the PCN-upper-
rate)

An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to
PCN-egress-nodes. PCN-traffic'. The PCN-marks shouldn't be visible outside the
PCN-domain, which can be achieved by doing the PCN-colour function
(Section 5.3) after measurement is
made as an aggregate of all the other (PCN PCN-packets, and tunnelling) functions. not per flow.

o Mark - algorithms determine whether to PCN-mark PCN-packets and
what packet encoding is used.

The potential reasons for doing such tunnelling are: the PCN-egress-
node then automatically knows functions are specified in [I-D.eardley-pcn-marking-behaviour]
and the address encodings in [I-D.moncaster-pcn-baseline-encoding] and
[I-D.moncaster-pcn-3-state-encoding].

7.2. PCN-ingress-node functions

Each ingress link of the relevant PCN-
ingress-node for a flow; even if ECMP PCN-domain is running, all PCN-packets on
a particular ingress-egress-aggregate follow the same path. But it
also has drawbacks, for example configured with the additional overhead in terms following
functionality:

o Packet classify - decide whether an incoming packet is part of
bandwidth a
previously admitted flow, by using a filter spec (eg DSCP, source
and processing, destination addresses and the cost of setting up port numbers).

o Police - police, by dropping or downgrading, any packets received
with a mesh of
tunnels between PCN-boundary-nodes (there is DSCP demanding PCN transport that do not belong to an N^2 scaling issue).

Potential issues arise for
admitted flow. Similarly, police packets that are part of a "partially PCN-capable tunnel", ie where

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 21] 19]

Internet-Draft Document February July 2008

only one tunnel endpoint is in

previously admitted flow, to check that the PCN domain:

1. The tunnel starts outside flow keeps to the
agreed rate or flowspec (eg RFC1633 [RFC1633] for a PCN-domain microflow and finishes inside it.
If the packet arrives at the tunnel ingress with
its NSIS equivalent).

o Packet colour - set the same
encoding DSCP and ECN fields appropriately, see
[I-D.moncaster-pcn-baseline-encoding] or
[I-D.moncaster-pcn-3-state-encoding] as used within appropriate for the PCN-domain PCN-
domain.

o Meter - some approaches to indicate PCN-marking,
then this could lead flow termination require the PCN-egress-node PCN-
ingress-node to falsely measure pre-
congestion.

2. The tunnel starts inside the (aggregate) rate of PCN-traffic
towards a particular PCN-egress-node.

The first two are policing functions, needed to make sure that PCN-
packets admitted into the PCN-domain belong to a flow that's been
admitted and finishes outside it.
If to ensure that the packet arrives flow keeps to the flowspec agreed (eg
doesn't go at a faster rate and is inelastic traffic). Installing
the tunnel ingress already PCN-marked,
then it filter spec will still have typically be done by the same encoding when it's decapsulated
which could potentially confuse nodes beyond signalling protocol, as
will re-installing the tunnel egress.

In line with filter, for example after a re-route that
changes the solution PCN-ingress-node (see [I-D.briscoe-tsvwg-cl-architecture]
for partially capable DiffServ tunnels in
[RFC2983], an example using RSVP). Packet colouring allows the following rules are applied:

o For case (1), rest of the tunnel
PCN-domain to recognise PCN-packets.

7.3. PCN-egress-node functions

Each egress node clears any PCN-marking on link of the
inner header. This rule PCN-domain is applied before configured with the 'copy on
decapsulation' rule above. following
functionality:

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

Note that the above implies that one Packet classify - determine which PCN-ingress-node a PCN-packet
has to know, come from.

o Meter - "measure PCN-traffic" or figure out, "monitor PCN-marks".

o Packet colour - for PCN-packets, set the
characteristics of DSCP and ECN fields to
the other end of appropriate values for use outside the tunnel as part PCN-domain.

The metering functionality of setting course depends on whether it
up.

5.8. Fault handling

If a PCN-interior-node fails (or one of its links), then lower layer
protection mechanisms is
targeted at admission control or flow termination. Alternative
proposals involve the regular IP routing protocol will
eventually re-route round it. If the new route can carry PCN-egress-node "measuring" as an aggregate (ie
not per flow) all PCN-packets from a particular PCN-ingress-node, or
"monitoring" the
admitted traffic, flows will gracefully continue. If instead this
causes early warning of pre-congestion on PCN-traffic and reacting to one (or several) PCN-
marked packets.

7.4. Other admission control functions

As well as the new route, then functions covered above, other specific admission
control based on pre-congestion notification will ensure
new flows will not functions can be admitted until enough existing flows have
departed. Re-routing may result in heavy (pre-)congestion, when the
flow termination mechanism will kick in.

If performed at a PCN-boundary-node fails then we would like the regular QoS
signalling protocol to take care of things. As an example
[I-D.briscoe-tsvwg-cl-architecture] considers what happens if RSVP is
the QoS signalling protocol. (PCN-
ingress-node or PCN-egress-node) or at a centralised node, but not at

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 22] 20]

Internet-Draft Document February July 2008

6. Design goals and challenges

Prior work

normal PCN-interior-nodes. The functions are:

o Make decision about admission - based on PCN and similar mechanisms has thrown up a number the output of
considerations about PCN's design goals (things the PCN-
egress-node's PCN should be good
at) and meter function. In the case where it "measures
PCN-traffic", the measured traffic on the ingress-egress-aggregate
is compared with some issues that have been hard to solve in a fully
satisfactory manner. Taken as a whole reference level. In the case where it represents a list
"monitors PCN-marks", then the decision is based on whether one
(or several) packets is (are) PCN-marked or not. In either case,
the admission decision also takes account of trade-
offs (it's unlikely that they can all policy and
application layer requirements.

o Communicate decision about admission - signal the decision to the
node making the admission control request (which may be 100% achieved) outside
the PCN-domain), and perhaps
as evaluation criteria to help an operator (or the IETF) decide
between options.

The following policer (PCN-ingress-node function)
for enforcement of the decision.

There are key design goals various possibilities for PCN (based on
[I-D.chan-pcn-problem-statement]): how the functionality can be
distributed (we assume the operator would configure which is used):

o The PCN-enabled packet forwarding network should be simple,
scalable decision is made at the PCN-egress-node and robust

o Compatibility with other traffic (ie a proposed solution should
work well when non-PCN traffic the decision
(admit or block) is also present in signalled to the network)

o Support of different types of real-time traffic (eg should work
well with CBR and VBR voice and video sources treated together) PCN-ingress-node. This seems
most natural.

o Reaction time of The decision is made at the mechanisms should be commensurate with PCN-ingress-node, which requires that
the
desired application-level requirements (eg a termination mechanism
needs PCN-egress-node signals PCN-feedback-information to terminate flows before significant QoS issues are
experienced by real-time traffic, and before most users hang up).

o Compatibility with different precedence levels of real-time
applications (e.g. preferential treatment the PCN-
ingress-node. For example, it could signal the current fraction
of higher precedence
calls over lower precedence calls, [ITU-MLPP].

The following are open issues. They are mainly taken from
[I-D.briscoe-tsvwg-cl-architecture] which also describes some
possible solutions. Note PCN-traffic that some may is PCN-marked.

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

7.5. Other flow termination functions

Specific termination control functions can be considered unimportant in
general performed at a PCN-
boundary-node (PCN-ingress-node or in specific deployment scenarios PCN-egress-node) or by some operators.

NOTE: Potential solutions at a
centralised node, but not at normal PCN-interior-nodes. There are out of scope
various possibilities for this document.

o ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion
is measured on a specific ingress-egress-aggregate. However, if how the PCN-domain runs ECMP, then traffic on this ingress-egress-
aggregate may follow several different paths - some of functionality can be distributed,
similar to those discussed above in the paths Admission control section;
the flow termination decision could be pre-congested whilst others are not. There are three
potential problems:

1. over-admission: a new flow is admitted (because made at the pre-
congestion level measured by PCN-ingress-node,
the PCN-egress-node or at some centralised node. The functions are:

o PCN-meter at PCN-egress-node - similarly to flow admission, there
are two types of proposals: to "measure PCN-traffic" on the
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" being sent towards a particular PCN-egress-node;
again, this is
sufficiently diluted by unmarked packets from non-congested done for the ingress-egress-aggregate and not per

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 23] 21]

Internet-Draft Document February July 2008

paths that 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

flow.

o (if required) Communicate PCN-feedback-information to the PCN-egress-node is
sufficiently increased by PCN-marked packets from pre-
congested paths node
that a new flow is blocked), but its packets
travel along an uncongested path

3. ineffective termination: flows are terminated, however their
path doesn't travel through makes the (pre-)congested router(s).
Since flow termination is a 'last resort' that protects decision. For example, as in
[I-D.briscoe-tsvwg-cl-architecture], communicate the
network should over-admission occur, this problem is probably
more important PCN-egress-
node's measurements to solve than the other two. PCN-ingress-node.

o ECMP and signalling: It is possible that, in a PCN-domain running
ECMP, Make decision about flow termination - use the signalling packets (eg RSVP, NSIS) follow a different
path than information from
the data packets, PCN-meter(s) to decide which could matter if the signalling
packets are used as probes. Whether this is an issue depends on
which fields the ECMP algorithm uses; if the ECMP algorithm is
restricted PCN-flow or PCN-flows to the source
terminate. The decision takes account of policy and destination IP addresses, then it
won't be. application
layer requirements.

o Tunnelling: There are scenarios where tunnelling makes it hard Communicate decision about flow termination - signal the decision
to
determine the path in node that is able to terminate the PCN-domain. The problem, its impact and flow (which may be
outside the potential solutions are similar PCN-domain), and to those for ECMP.

o Scenarios with only one tunnel endpoint in the PCN domain may make
it harder policer (PCN-ingress-node
function) for enforcement of the PCN-egress-node decision.

7.6. Addressing

PCN-nodes may need to gather from the signalling
messages (eg RSVP, NSIS) know the identity address of other PCN-nodes. Note: in
all cases PCN-interior-nodes don't need to know the PCN-ingress-node.

o Bi-Directional Sessions: Many applications have bi-directional
sessions - hence there are two flows that should be admitted (or
terminated) address of any
other PCN-nodes (except as a pair - normal their next hop neighbours, for instance a bi-directional voice call
only makes sense if flows in both directions are admitted.
However, PCN's mechanisms concern admission and termination
routing purposes).

The PCN-egress-node needs to know the address of the PCN-ingress-node
associated with a
single flow, and coordination of at a minimum so that the PCN-ingress-node can
be informed to enforce the admission decision (and any flow
termination decision) through policing. There are various
possibilities for both flows how the PCN-egress-node can do this, ie associate
the received packet to the correct ingress-egress-aggregate. It is a
matter for
not the signalling protocol and out of scope intention of PCN. One
possible example would use SIP pre-conditions; there are others.

o Global Coordination: PCN makes its admission decision based on
PCN-markings on this document to mandate a particular ingress-egress-aggregate. Decisions
about flows through a different ingress-egress-aggregate are made
independently. However, one mechanism.

o The addressing information can imagine network topologies and
traffic matrices where, from a global perspective, it would be
better gathered from signalling. For
example, regular processing of an RSVP Path message, as the PCN-
ingress-node is the previous RSVP hop (PHOP)
([I-D.lefaucheur-rsvp-ecn]). Or the PCN-ingress-node could signal
its address to make a coordinated decision across all the ingress-
egress-aggregates for PCN-egress-node.

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

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 24] 22]

Internet-Draft Document February July 2008

more important flows through a different ingress-egress-aggregate
could be admitted. The problem

7.7. Tunnelling

Tunnels may well be second order.

o Aggregate Traffic Characteristics: Even when originate and/or terminate within a PCN-domain. It is
important that the number PCN-marking of flows
is stable, any packet can potentially
influence PCN's flow admission control and termination - it shouldn't
matter whether the traffic level through packet happens to be tunnelled at the PCN-domain will vary
because PCN-node
that PCN-marks the sources vary their traffic rates. PCN works best when
there's not too much variability in the total traffic level at a
PCN-node's interface (ie in the aggregate traffic 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 packet, or indeed whether it's overloaded. decapsulated or
encapsulated by a subsequent PCN-node. This makes it hard to tune
the admission control scheme to stop admitting new flows at suggests that the
right time. Therefore
"uniform conceptual model" described in [RFC2983] should be re-
applied in the problem is more likely PCN context. In line with fewer,
burstier flows.

o Flash crowds this and Speed the approach of Reaction: PCN is a measurement-based
mechanism
[RFC4303] and so there [I-D.briscoe-tsvwg-ecn-tunnel], the following rule is an inherent delay between packet marking
by PCN-interior-nodes and any admission control reaction at PCN-
boundary-nodes. For example, potentially
applied if a big burst of
admission requests occurs in a very short space of time (eg
prompted by a televote), they could all get admitted before enough
PCN-marks are seen to block new flows. In other words, any
additional load offered encapsulation is done within the reaction time of the mechanism
mustn't move PCN-domain:

o any PCN-marking is copied into the PCN-domain directly from no congestion to
overload. This 'vulnerability period' may impact at outer header

Similarly, in line with the
signalling level, for instance QoS requests should be rate limited
to bound "uniform conceptual model" of [RFC2983]
and the number "full-functionality option" of requests able to arrive [RFC3168], the following rule
is applied if decapsulation is done within the
vulnerability period. PCN-domain:

o Silent at start: after a successful admission request the source
may wait some time before sending data (eg waiting for the called
party to answer). Then if the risk outer header's marking state is that, in some circumstances,
PCN's measurements underestimate what the pre-congestion level
will be when more severe then it is
copied onto the source does start sending data. inner header

o Compatibility of PCN-encoding with ECN-encoding. This issue will
be considered further in Note: the PCN WG Milestone 'Survey order of encoding
choices'.

7. Probing

7.1. Introduction

Probing is an optional mechanism increasing severity is: not PCN-marked;
threshold-marking; excess-traffic-marking.

An operator may wish to assist admission control.

PCN's admission control, as described so far, is essentially a
reactive mechanism where 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 monitors doing the pre-

Eardley (Editor) Expires August 11, 2008 [Page 25]

Internet-Draft Document February 2008

congestion level for traffic from each PCN-ingress-node; if
packet colouring function (Section 7.3) after all 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, other (PCN and so
tunnelling) functions. The potential reasons for doing such
tunnelling are: the PCN-egress-node can't make an admission decision
using then automatically knows the usual method described earlier.

One approach is to be "optimistic" and simply admit
address of the new flow.
However it's possible to envisage relevant PCN-ingress-node for a scenario where the traffic levels flow; even if ECMP is
running, all PCN-packets on other ingress-egress-aggregates are already so high that they're
blocking new PCN-flows, and admitting a new flow onto this 'empty' particular ingress-egress-aggregate adds extra traffic onto the link that's
already pre-congested - which may 'tip the balance' so that PCN's
flow termination mechanism is activated or some packets are dropped.
This risk could be lessened by configuring on each link sufficient
'safety margin' above the PCN-lower-rate.

An alternative approach is to make PCN a more proactive mechanism.
The PCN-ingress-node explicitly determines, before admitting
follow the
prospective new flow, whether same path. But it also has drawbacks, for example the ingress-egress-aggregate can
support it. This can be seen as a "pessimistic" approach,
additional overhead in
contrast to the "optimism" terms of the approach above. It involves
probing: a PCN-ingress-node generates bandwidth and processing, and sends probe packets in
order to test the pre-congestion level that the flow would
experience.

One possibility is that
cost of setting up a probe packet mesh of tunnels between PCN-boundary-nodes
(there is just an N^2 scaling issue).

Potential issues arise for a dummy data packet,
generated by "partially PCN-capable tunnel", ie where
only one tunnel endpoint is in the PCN-ingress-node PCN domain:

1. The tunnel starts outside a PCN-domain and addressed to finishes inside it.
If the PCN-egress-
node. Another possibility is that a probe packet is a signalling packet that is anyway travelling from arrives at the PCN-ingress-node to tunnel ingress with the
PCN-egress-node (eg an RSVP PATH message travelling from source same
encoding as used within the PCN-domain to
destination).

7.2. Probing functions

The probing functions are:

o Make decision that probing is needed. As described above, indicate PCN-marking,
then this is
when the ingress-egress-aggregate (or could lead the ECMP path - Section 6)
carries no PCN-traffic. An alternative is always PCN-egress-node 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 falsely measure pre-
congestion.

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 26] 23]

Internet-Draft Document February July 2008

example an excess-rate-marking algorithm generates fewer PCN-marks
than

2. The tunnel starts inside a threshold-marking algorithm, PCN-domain and so finishes outside it.
If the packet arrives at the tunnel ingress already PCN-marked,
then it will need more probe
packets.

o Forward probe packets - as far as PCN-interior-nodes are
concerned, probe packets must be handled still have 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 encoding when it's decapsulated
which could potentially confuse nodes beyond the PCN-domain.

7.3. Discussion of rationale tunnel egress.

In line with the solution for probing, its downsides and open issues

It is an unresolved question whether probing is really needed, but
three viewpoints have been put forward as to why it is useful. The
first is perhaps partially capable DiffServ tunnels in
[RFC2983], the most obvious: there is no PCN-traffic following rules are applied:

o For case (1), the tunnel egress node clears any PCN-marking on the
ingress-egress-aggregate. The second assumes that multipath routing
ECMP
inner header. This rule is running in applied before the PCN-domain. The third viewpoint is that
admission control is always done by probing. We now consider each in
turn.

The first viewpoint assumes the following: 'copy on
decapsulation' rule above.

o There is no PCN-traffic For case (2), the tunnel ingress node clears any PCN-marking on
the ingress-egress-aggregate (so a
normal admission decision cannot be made).

o Simply admitting inner header. This rule is applied after the new flow 'copy on
encapsulation' rule above.

Note that the above implies that one has a significant risk of leading to
overload: packets dropped know, or flows terminated.

On figure out, the former bullet, [PCN-email-traffic-empty-aggregates] suggests
that, during
characteristics of the future busy hour other end of a national network with about
100 PCN-boundary-nodes, there are likely to be significant numbers the tunnel as part of
aggregates with very few flows under nearly all circumstances.

The latter bullet could occur if setting it
up.

Tunnelling constraints were a new flow starts on many of major factor in the
empty ingress-egress-aggregates and causes overload on a link choice of encoding,
as explained in [I-D.moncaster-pcn-baseline-encoding] and
[I-D.moncaster-pcn-3-state-encoding]. A lengthy discussion of all
the
PCN-domain. To be a problem this would probably have to happen issues associated with layered encapsulation of congestion
notification (for ECN as well as PCN) is in
[I-D.briscoe-tsvwg-ecn-tunnel].

7.8. Fault handling

If a
short time period (flash crowd) because, after the reaction time PCN-interior-node fails (or one of its links), then lower layer
protection mechanisms or the system, other (non-empty) ingress-egress-aggregates that pass
through the link regular IP routing protocol will measure pre-congestion and so block
eventually re-route round it. If the new flows,
and also route can carry all the
admitted traffic, flows naturally end anyway.

The downsides of probing for will gracefully continue. If instead this viewpoint are:

o Probing adds delay to
causes early warning of pre-congestion on the new route, then
admission control process. based on pre-congestion notification will ensure
new flows will not be admitted until enough existing flows have
departed. Re-routing may result in heavy (pre-)congestion, when the
flow termination mechanism will kick in.

If a PCN-boundary-node fails then we would like the regular QoS
signalling protocol to take care of things. As an example
[I-D.briscoe-tsvwg-cl-architecture] considers what happens if RSVP is
the QoS signalling protocol.

8. Design goals and challenges

Prior work on PCN and similar mechanisms has thrown up a number of

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 27] 24]

Internet-Draft Document February July 2008

o Sufficient probing traffic has to

considerations about PCN's design goals (things PCN should be generated good
at) and some issues that have been hard to test the pre-
congestion level solve in a fully
satisfactory manner. Taken as a whole it represents a list of the ingress-egress-aggregate. But the probing
traffic itself may cause pre-congestion, causing other PCN-flows
to trade-
offs (it's unlikely that they can all be blocked or even terminated - 100% achieved) and in perhaps
as evaluation criteria to help an operator (or the flash crowd scenario
there will be probing IETF) decide
between options.

The following are key design goals for PCN (based on many ingress-egress-aggregates.
[I-D.chan-pcn-problem-statement]):

o The open issues associated PCN-enabled packet forwarding network should be simple,
scalable and robust

o Compatibility with this viewpoint include: other traffic (ie a proposed solution should
work well when non-PCN traffic is also present in the network)

o What rate and pattern Support of probe packets does the PCN-ingress-node
need to generate, so that there's enough different types of real-time traffic to make the
admission decision? (eg should work
well with CBR and VBR voice and video sources treated together)

o What difficulty does Reaction time of the delay (whilst probing is done) cause
applications, eg packets might mechanisms should be dropped?

o Are there other ways of dealing commensurate with the flash crowd scenario?
For instance limit the rate at which new flows are admitted; or
perhaps for
desired application-level requirements (eg a PCN-egress-node termination mechanism
needs to block new terminate flows on its empty
ingress-egress-aggregates when its non-empty ones before significant QoS issues are pre-
congested.
experienced by real-time traffic, and before most users hang up).

o Compatibility with different precedence levels of real-time
applications (eg preferential treatment of higher precedence calls
over lower precedence calls, [ITU-MLPP]).

The second viewpoint applies in the case where there is multipath
routing (ECMP) in the PCN-domain. following are open issues. They are mainly taken from
[I-D.briscoe-tsvwg-cl-architecture] which also describes some
possible solutions. Note that some may be considered unimportant in
general or in specific deployment scenarios or by some operators.

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

o ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion
is often used measured on
core networks. 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 two possibilities:

(1) If admission control three
potential problems:

1. over-admission: a new flow is based on measurements of admitted (because the ingress-
egress-aggregate, then pre-
congestion level measured by the viewpoint that probing PCN-egress-node is useful assumes:

o there's a significant chance
sufficiently diluted by unmarked packets from non-congested
paths that the traffic a new flow is unevenly balanced
across the ECMP paths, and hence there's admitted), but its packets travel
through a significant risk of
admitting pre-congested PCN-node

Eardley (Editor) Expires January 15, 2009 [Page 25]

Internet-Draft Document July 2008

2. under-admission: a new flow that should be is blocked (because it follows an
ECMP path that the pre-
congestion level measured by the PCN-egress-node is pre-congested) or blocking
sufficiently increased by PCN-marked packets from pre-
congested paths that a new flow that should be
admitted.

o Note: [PCN-email-ECMP] suggests unbalanced traffic is quite
possible, even with quite a large number of blocked), but its packets
travel along an uncongested path

3. ineffective termination: flows on are terminated, however their
path doesn't travel through the (pre-)congested router(s).
Since flow termination is a PCN-link
(eg 1000) when Assumption 3 (aggregation) 'last resort' that protects the
network should over-admission occur, this problem is likely probably
more important to be
satisfied.

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

o There ECMP and signalling: It is no PCN-traffic on possible that, in a PCN-domain running
ECMP, the ECMP signalling packets (eg RSVP, NSIS) follow a different
path on than the data packets, which to base could matter if the signalling
packets are used as probes. Whether this is an
admission decision.

o Simply admitting issue depends on
which fields the new flow has a significant risk of leading to
overload.

Eardley (Editor) Expires August 11, 2008 [Page 28]

Internet-Draft Document February 2008

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

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

The downsides specific
instance of probing a general issue for this viewpoint are:

o Probing adds delay to the admission control process. non-traditional routing combined
with resource management along a path [Hancock].

o Sufficient probing traffic has to be generated Tunnelling: There are scenarios where tunnelling makes it hard to test the pre-
congestion level of
determine the ECMP path. But there's path in the risk that PCN-domain. The problem, its impact and
the
probing traffic itself may cause pre-congestion, causing other
PCN-flows potential solutions are similar to be blocked or even terminated. those for ECMP.

o The PCN-egress-node needs to consume Scenarios with only one tunnel endpoint in the probe packets PCN domain may make
it harder for the PCN-egress-node to ensure
they don't travel beyond gather from the PCN-domain signalling
messages (eg they might confuse RSVP, NSIS) the
destination end node). Hence somehow identity of the PCN-egress-node has to
be able to disambiguate a probe packet from a data packet, via the
characteristic setting of particular bit(s) in the packet's header
or body PCN-ingress-node.

o Bi-Directional Sessions: Many applications have bi-directional
sessions - but these bit(s) mustn't be used by any PCN-interior-
node's ECMP algorithm. In the general case this isn't possible,
but it hence there are two flows that should be OK admitted (or
terminated) as a pair - for instance a typical ECMP algorithm which examines:
the source bi-directional voice call
only makes sense if flows in both directions are admitted.
However, PCN's mechanisms concern admission and destination IP addresses termination of a
single flow, and port numbers, coordination of the decision for both flows is a
matter for the signalling protocol ID and the DSCP.

The third viewpoint assumes the following: out of scope of PCN. One
possible example would use SIP pre-conditions; there are others.

o Every Global Coordination: PCN makes its admission control decision involves probing, using the
signalling set-up message as the probe packet (eg RSVP PATH).

o The PCN-marking behaviour is such that every packet is PCN-marked
if the flow should be blocked, hence only based on
PCN-markings on a single probing packet
is needed.

This viewpoint [I-D.draft-babiarz-pcn-3sm] has in particular been
suggested for the scenario where the PCN-domain reaches out towards
the end terminals (note that it's assumed the trust ingress-egress-aggregate. Decisions
about flows through a different ingress-egress-aggregate are made
independently. However, one can imagine network topologies and aggregation
assumptions still hold), although
traffic matrices where, from a global perspective, it has also been suggested for
other scenarios.

Eardley (Editor) Expires August 11, 2008 would be
better to make a coordinated decision across all the ingress-
egress-aggregates for the whole PCN-domain. For example, to block
(or even terminate) flows on one ingress-egress-aggregate so that
more important flows through a different ingress-egress-aggregate

Eardley (Editor) Expires January 15, 2009 [Page 29] 26]

Internet-Draft Document February July 2008

8. Operations and Management

This Section considers operations and management issues, under

could be admitted. The problem may well be second order.

o Aggregate Traffic Characteristics: Even when the
FCAPS headings: OAM number of Faults, Configuration, Accounting, Performance
and Security. Provisioning flows
is discussed with performance.

8.1. Configuration OAM

This architecture document predates stable, the detailed standards actions of traffic level through the PCN WG. Here we assume that only interoperable PCN-marking
behaviours PCN-domain will be standardised, otherwise we would have to consider
how to avoid interactions between non-interoperable marking
behaviours. However, more diversity in PCN-boundary-node behaviours
is expected, vary
because the sources vary their traffic rates. PCN works best when
there's not too much variability in order to the total traffic level at a
PCN-node's interface with diverse industry
architectures. It (ie in the aggregate traffic from all
sources). Too much variation means that a node may (at one
moment) not be possible doing any PCN-marking and then (at another moment)
drop packets because it's overloaded. This makes it hard to have different PCN-boundary-
node behaviours for different ingress-egress-aggregates within tune
the
same PCN-domain.

PCN functionality is configured on either admission control scheme to stop admitting new flows at the egress or
right time. Therefore the ingress
interfaces problem is more likely with fewer,
burstier flows.

o Flash crowds and Speed of PCN-nodes. A consistent choice must be made across the
PCN-domain to ensure that the PCN mechanisms protect all links. Reaction: PCN configuration control variables fall into the following
categories:

o system options (enabling or disabling behaviours)

o parameters (setting levels, addresses etc)

One possibility is that all configurable variables sit within an SNMP
management framework [RFC3411], being structured within a defined
management information base (MIB) on each node, measurement-based
mechanism and being remotely
readable so there is an inherent delay between packet marking
by PCN-interior-nodes and settable via any admission control reaction at PCN-
boundary-nodes. For example, potentially if a suitably secure management protocol
(SNMPv3).

Some configuration options and parameters have to be set once big burst of
admission requests occurs in a very short space of time (eg
prompted by a televote), they could all get admitted before enough
PCN-marks are seen to
'globally' control block new flows. In other words, any
additional load offered within the whole PCN-domain. Where possible, these are
identified below. reaction time of the mechanism
mustn't move the PCN-domain directly from no congestion to
overload. This 'vulnerability period' may affect operational complexity and impact at the
chances
signalling level, for instance QoS requests should be rate limited
to bound the number of interoperability problems between kit from different
vendors.

It requests able to arrive within the
vulnerability period.

o Silent at start: after a successful admission request the source
may be possible wait some time before sending data (eg waiting for an operator the called
party to configure answer). Then the risk is that, in some PCN-interior-
nodes so they don't run circumstances,
PCN's measurements underestimate what the PCN mechanisms, if it knows that these
links pre-congestion level
will never become (pre-)congested. be when the source does start sending data.

9. Operations and Management

This Section considers operations and management issues, under the
FCAPS headings: OAM of Faults, Configuration, Accounting, Performance
and Security. Provisioning is discussed with performance.

9.1. Configuration OAM

This architecture document predates the detailed standards actions of
the PCN WG. Here we assume that only inter-operable PCN-marking
behaviours will be standardised, otherwise we would have to consider
how to avoid interactions between non inter-operable marking
behaviours. However, more diversity in PCN-boundary-node behaviours

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 30] 27]

Internet-Draft Document February July 2008

8.1.1. System options

On PCN-interior-nodes there will

is expected, in order to interface with diverse industry
architectures. It may be very few system options:

o Whether two PCN-markings (based possible to have different PCN-boundary-
node behaviours for different ingress-egress-aggregates within the
same PCN-domain.

PCN functionality is configured on either the PCN-lower-rate and PCN-
upper-rate) are enabled egress or only one (see Section 4.3). Typically
all nodes throughout a PCN-domain will be configured the same in
this respect. However, exceptions could be made. For example, if
most PCN-nodes used both markings, but some legacy hardware was
incapable ingress
interfaces of running two algorithms, an operator might PCN-nodes. A consistent choice must be willing
to configure these legacy nodes solely for PCN-marking based on made across the PCN-upper-rate to enable flow termination as a back-stop. It
would be sensible
PCN-domain to place such nodes where they could be
provisioned with a greater leeway over expected traffic levels. ensure that the PCN mechanisms protect all links.

PCN configuration control variables fall into the following
categories:

o which marking algorithm to system options (enabling or disabling behaviours)

o parameters (setting levels, addresses etc)

Some configuration options and parameters have to be set once to
'globally' control the whole PCN-domain. Where possible, these are
identified below. This may affect operational complexity and the
chances of interoperability problems between kit from different
vendors.

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

9.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 will be configured the 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 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 greater leeway over
expected traffic levels.

Eardley (Editor) Expires January 15, 2009 [Page 28]

Internet-Draft Document July 2008

o what marking algorithm to use, if an equipment vendor provides a
choice
choice.

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

o Which of admission and flow termination are enabled. If any PCN-
interior-node is configured to generate a marking, all PCN-
boundary-nodes must be able to handle that marking. Therefore all
PCN-boundary-nodes must be configured the same in this respect.

o Where flow admission and termination decisions are made: at the
PCN-ingress-node, PCN-egress-node or at a centralised node (see
Sections 5.4 and 5.5).
Section 7). 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.

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

8.1.2.

9.1.2. Parameters

Like any DiffServ domain, every node within a PCN-domain will need to
be configured with the DSCP(s) used to identify PCN-packets. On each
interior link the main configuration parameters are the PCN-lower-
rate PCN-
threshold-rate and PCN-upper-rate. PCN-excess-rate. A larger PCN-lower-rate PCN-threshold-rate
enables more PCN-

Eardley (Editor) Expires August 11, 2008 [Page 31]

Internet-Draft Document February 2008

traffic PCN-traffic to be admitted on a link, hence improving
capacity utilisation. A PCN-upper-rate PCN-excess-rate set further above the PCN-lower-rate PCN-
threshold-rate allows greater increases in traffic (whether due to
natural fluctuations or some unexpected event) before any flows are
terminated, ie minimises the chances of unnecessarily triggering the
termination mechanism. For instance an operator may want to design
their network so that it can cope with a failure of any single PCN-
node without terminating any flows.

Setting these rates on first deployment of PCN will be very similar
to the traditional process for sizing an admission controlled
network, depending on: the operator's requirements for minimising
flow blocking (grade of service), the expected PCN traffic load on
each link and its statistical characteristics (the traffic matrix),
contingency for re-routing the PCN traffic matrix in the event of
single or multiple failures and

Eardley (Editor) Expires January 15, 2009 [Page 29]

Internet-Draft Document July 2008

single or multiple failures and the expected load from other classes
relative to link capacities [Menth]. But once a domain is up and
running, a PCN design goal is to be able to determine growth in these
configured rates much more simply, by monitoring PCN-marking rates
from actual rather than expected traffic (see Section 8.2 9.2 on
Performance & Provisioning).

Operators may also wish to configure a rate greater than the PCN-
upper-rate
excess-rate that is the absolute maximum rate that a link allows for
PCN-traffic. This may simply be the physical link rate, but some
operators may wish to configure a logical limit to prevent starvation
of other traffic classes during any brief period after PCN-traffic
exceeds the PCN-upper-rate PCN-excess-rate but before flow termination brings it
back below this rate.

Specific marking algorithms will also depend on further configuration
parameters. For instance, threshold-marking will require a threshold
queue depth and excess-rate-marking excess-traffic-marking may require a scaling
parameter. It will be preferable for each marking algorithm to have
rules to set defaults for these parameters relative to the reference
marking rate, but then allow operators to change them, for instance
if average traffic characteristics change over time. The PCN-egress-node PCN-egress-
node may allow configuration of the following:

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

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

Eardley (Editor) Expires August 11, 2008 [Page 32]

Internet-Draft Document February 2008

o Any any admission control algorithm will at least require a marking
threshold setting above which it denies admission to new flows;

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

o a parameter to control the trade-off between how quickly excess
flows are terminated and over-termination.

One particular proposal, [I-D.charny-pcn-single-marking] would
require a global parameter to be defined on all PCN-nodes, but only
needs the PCN-lower-rate one PCN marking rate to be configured on each link. The global
parameter is a scaling factor between admission and termination, for
example the amount by which the PCN-upper-rate PCN-excess-rate is implicitly assumed
to be above the PCN-lower-rate. PCN-threshold-rate. [I-D.charny-pcn-single-marking]
discusses in full the impact of this particular proposal on the

Eardley (Editor) Expires January 15, 2009 [Page 30]

Internet-Draft Document July 2008

operation of PCN.

8.2.

9.2. Performance & Provisioning OAM

Monitoring of performance factors measurable from *outside* the PCN
domain will be no different with PCN than with any other packet-based
flow admission control system, both at the flow level (blocking
probability etc) and the packet level (jitter [RFC3393], [Y.1541],
loss rate [RFC4656], mean opinion score [P.800], etc). The
difference is that PCN is intentionally designed to indicate
*internally* which exact resource(s) are the cause of performance
problems and by how much.

Even better, PCN indicates which resources will probably cause
problems if they are not upgraded soon. This can be achieved by the
management system monitoring the total amount (in bytes) of PCN-
marking generated by each queue over a period. Given possible long
provisioning lead times, pre-congestion volume is the best metric to
reveal whether sufficient persistent demand has mounted up to warrant
an upgrade. Because, even before utilisation becomes problematic,
the statistical variability of traffic will cause occasional bursts
of pre-congestion. This 'early warning system' decouples the process
of adding customers from the provisioning process. This should cut
the time to add a customer when compared against admission control
provided over native DiffServ [RFC2998], because it saves having to
re-run the capacity planning process before adding each customer.

Alternatively, before triggering an upgrade, the long term pre-
congestion volume on each link can be used to balance traffic load
across the PCN-domain by adjusting the link weights of the routing
system. When an upgrade to a link's configured PCN-rates is

Eardley (Editor) Expires August 11, 2008 [Page 33]

Internet-Draft Document February 2008
required, it may also be necessary to upgrade the physical capacity
available to other classes. But usually there will be sufficient
physical capacity for the upgrade to go ahead as a simple
configuration change. Alternatively, [Songhurst] has proposed an
adaptive rather than preconfigured system, where the configured PCN-
lower-rate
threshold-rate is replaced with a high and low water mark and the
marking algorithm automatically optimises how physical capacity is
shared using the relative loads from PCN and other traffic classes.

All the above processes require just three extra counters associated
with each PCN queue: PCN-markings associated with the PCN-lower-rate
and PCN-upper-rate, threshold-markings, excess-traffic-markings and
drop. Every time a PCN packet is marked or dropped its size in bytes
should be added to the appropriate counter. Then the management
system can read the counters at any time and subtract a previous
reading to establish the incremental volume of each type of
(pre-)congestion. Readings should be taken frequently, so that
anomalous events (eg re-routes) can be separated from regular

Eardley (Editor) Expires January 15, 2009 [Page 31]

Internet-Draft Document July 2008

fluctuating demand if required.

8.3.

9.3. Accounting OAM

Accounting is only done at trust boundaries so it is out of scope of
the initial Charter of the PCN WG which is confined to intra-domain
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.

8.4.

9.4. Fault OAM

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

Admission blocking and particularly flow termination mechanisms
should rarely be needed in practice. It would be unfortunate if they
didn't work after an option had been accidentally disabled.
Therefore it will be necessary to regularly test that the live system
works as intended (devising a meaningful test is left as an exercise
for the operator).

Section 5.9 7 describes how the PCN architecture has been designed to
ensure admitted flows continue gracefully after recovering
automatically from link or node failures. The need to record and
monitor re-routing events affecting signalling is unchanged by the
addition of PCN to a DiffServ domain. Similarly, re-routing events
within the PCN-domain will be recorded and monitored just as they
would be without PCN.

Eardley (Editor) Expires August 11, 2008 [Page 34]

Internet-Draft Document February 2008

PCN-marking does make it possible to record 'near-misses'. For
instance, at the PCN-egress-node a 'reporting threshold' could be set
to monitor how often - and for how long - the system comes close to
triggering flow blocking without actually doing so. Similarly,
bursts of flow termination marking could be recorded even if they are
not sufficiently sustained to trigger flow termination. Such
statistics could be correlated with per-queue counts of marking
volume (Section 8.2) 9.2) to upgrade resources in danger of causing
service degradation, or to trigger manual tracing of intermittent
incipient errors that would otherwise have gone unnoticed.

Finally, of course, many faults are caused by failings in the
management process ('human error'): a wrongly configured address in a
node, a wrong address given in a signalling protocol, a wrongly
configured parameter in a queueing algorithm, a node set into a
different mode from other nodes, and so on. Generally, a clean
design with few configurable options ensures this class of faults can

Eardley (Editor) Expires January 15, 2009 [Page 32]

Internet-Draft Document July 2008

be traced more easily and prevented more often. Sound management
practice at run-time also helps. For instance: a management system
should be used that constrains configuration changes within system
rules (eg preventing an option setting inconsistent with other
nodes); configuration options should also be recorded in an offline
database; and regular automatic consistency checks between live
systems and the database. PCN adds nothing specific to this class of
problems. By the time standards are in place, we expect that the PCN
WG will have ruthlessly removed gratuitous configuration choices.
However, at the time of writing, the WG is yet to choose between
multiple competing proposals, so the range of possible options in
Section 8.1 9.1 does seem rather wide compared to the original near-zero
configuration intent of the architecture.

8.5.

9.5. Security OAM

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

Eardley (Editor) Expires August 11, 2008 [Page 35]

Internet-Draft Document February 2008

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

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

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

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

Eardley (Editor) Expires January 15, 2009 [Page 33]

Internet-Draft Document July 2008

10. IANA Considerations

This memo includes no request to IANA.

10.

11. Security considerations

Security considerations essentially come from the Trust Assumption
(Section 3.1), 5.1), ie that all PCN-nodes are PCN-enabled and trust each
other 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 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 to make and the kinds
of information they need to make them. For example when the PCN-
boundary-node needs to know the contents of the sessions for
making the admission and termination decisions, or when the
contents are highly classified, then the security requirements for
the PCN-boundary-nodes involved will also need to be high.

o the PCN-ingress-nodes police packets to ensure a PCN-flow sticks
within its agreed limit, and to ensure that only PCN-flows which
have been admitted contribute PCN-traffic into the PCN-domain.
The policer must drop (or perhaps re-mark downgrade to a different DSCP)
any PCN-packets received that are outside this remit. This is
similar

Eardley (Editor) Expires August 11, 2008 [Page 36]

Internet-Draft Document February 2008 to the existing IntServ behaviour. Between them the PCN-boundary-
nodes PCN-
boundary-nodes must encircle the PCN-domain, otherwise PCN-packets
could enter the PCN-domain without being subject to admission
control, which would potentially destroy the QoS of existing
flows.

o PCN-interior-nodes aren't flow-aware. This prevents some security
attacks where an attacker targets specific flows in the data plane
- for instance for DoS or eavesdropping.

o PCN-marking by the PCN-interior-nodes along the packet forwarding
path needs to be trusted, because the PCN-boundary-nodes rely on
this information. 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's pre-congested. More subtly, the rogue PCN-interior-node
could perform these attacks selectively on particular flows, or it
could PCN-mark the correct fraction overall, but carefully choose
which flows it marked.

Eardley (Editor) Expires January 15, 2009 [Page 34]

Internet-Draft Document July 2008

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 (and possibly a
central control node) must be protected from attacks. For example
the recipient needs to validate that the message is indeed from
the node that claims to have sent it. Possible measures include
digest authentication and protection against replay and man-in-
the-middle attacks. For the specific protocol RSVP, hop-by-hop
authentication is in [RFC2747], and
[I-D.behringer-tsvwg-rsvp-security-groupkeying] may also be
useful; for a generic signalling protocol the PCN WG document on
"Requirements for signalling" will describe the requirements in
more detail.

Operational security advice is given in Section 8.5.

11. 9.5.

12. Conclusions

The document describes a general architecture for flow admission and
termination based on pre-congestion information in order to protect
the quality of service of established inelastic flows within a single
DiffServ domain. The main topic is the functional architecture
(first covered at a high level and then at a greater level of
detail). architecture. It
also mentions other topics like the assumptions and open issues.

Eardley (Editor) Expires August 11, 2008 [Page 37]

Internet-Draft Document February 2008

12.

13. Acknowledgements

This document is a revised version of [I-D.eardley-pcn-architecture].
Its authors were: 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've made comments on
[I-D.eardley-pcn-architecture] and on earlier versions of this draft:
Lachlan Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake,
Bob Briscoe, Jason Canon, Ken Carlberg, Anna Charny, Joachim
Charzinski, Andras Csaszar, Lars Eggert, Ruediger Geib, Wei Gengyu,
Robert Hancock, Ingemar Johansson, Georgios Karagiannis, Michael
Menth, Toby Moncaster, Ben Strulo, Tom Taylor, Hannes Tschofenig,
Tina Tsou, Lars Westberg, Magnus Westerlund, Delei Yu. Thanks to Bob
Briscoe who extensively revised the Operations and Management
section.

This document is the result of discussions in the PCN WG and
forerunner activity in the TSVWG. A number of previous drafts were

Eardley (Editor) Expires January 15, 2009 [Page 35]

Internet-Draft Document July 2008

presented to TSVWG: [I-D.chan-pcn-problem-statement],
[I-D.briscoe-tsvwg-cl-architecture], [I-D.briscoe-tsvwg-cl-phb],
[I-D.charny-pcn-single-marking], [I-D.babiarz-pcn-sip-cap],
[I-D.lefaucheur-rsvp-ecn], [I-D.westberg-pcn-load-control]. The
authors of them 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.

13.

14. Comments Solicited

Comments and questions are encouraged and very welcome. They can be
addressed to the IETF PCN working group mailing list <pcn@ietf.org>.

14.

15. Changes

14.1.

15.1. Changes from -02 to -03 to -04

o Abstract: Clarified by removing Minor changes throughout to reflect the term 'aggregated'. Follow-up
clarifications later consenus call about PCN-
marking (as reflected in draft: S1: expanded PCN-egress-nodes
bullet [I-D.eardley-pcn-marking-behaviour]).

o Minor changes throughout to mention case where reflect the PCN-feedback-information is current decisions about
one (or a few) PCN-marks, rather than aggregated information; S3
clarified PCN-meter; S5 minor changes; conclusion.
encoding (as reflected in [I-D.moncaster-pcn-baseline-encoding]and
[I-D.moncaster-pcn-3-state-encoding]).

o S1: added a paragraph about how the PCN-domain looks Introduction: re-structured to the
outside world (essentially it looks like create new sections on Benefits,
Deployment scenarios and Assumptions.

o Introduction: Added pointers to other PCN documents.

o Terminology: changed PCN-lower-rate to PCN-threshold-rate and PCN-
upper-rate to PCN-excess-rate; excess-rate-marking to excess-
traffic-marking.

o Benefits: added bullet about SRLGs.

o Deployment scenarios: new section combining material from various
places within the document.

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

o S6.4: added claim that the most natural place to make an admission
decision is a DiffServ domain). PCN-egress-node.

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 38] 36]

Internet-Draft Document February July 2008

o S6.5: updated the bullet about non-PCN-traffic that uses the same
DSCP as PCN-traffic.

o S6.6: added a section about backwards compatibility with respect
to [RFC4774].

o Appendix A: added bullet about end-to-end PCN.

o Probing: moved to Appendix B.

o Other minor clarifications, typos etc.

15.2. Changes from -02 to -03

o Abstract: Clarified by removing the term 'aggregated'. Follow-up
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.

o S1: added a paragraph about how the PCN-domain looks to the
outside world (essentially it looks like a DiffServ domain).

o S2: tweaked the PCN-traffic terminology bullet: changed PCN
traffic classes to PCN behaviour aggregates, to be more in line
with traditional DiffServ jargon (-> follow-up changes later in
draft); included a definition of PCN-flows (and corrected a couple
of 'PCN microflows' to 'PCN-flows' later in draft)

o S3.5: added possibility 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 PCN operating on an
interface or on a link. In S8.1 (OAM) mentioned a link. In S8.1 (OAM) mentioned that PCN
functionality needs to be configured consistently on either the
ingress or the egress interface of PCN-nodes in a PCN-domain.

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

o S5.6: addressing: clarified

o S5.7: added tunnelling issue of N^2 scaling if you set up a mesh
of tunnels between PCN-boundary-nodes

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

Eardley (Editor) Expires January 15, 2009 [Page 37]

Internet-Draft Document July 2008

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 possible to have different PCN-boundary-node
behaviours for different ingress-egress-aggregates within the same
PCN-domain.

o Appendix: Created an Appendix about "Possible work items beyond
the scope of the current PCN WG Charter". Material moved from
near start of S3 and elsewhere throughout draft. Moved text about
centralised decision node to Appendix.

o Other minor clarifications.

15.3. Changes from -01 to -02

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

o S1: Deployment models: mentioned, as variant of PCN-domain
extending to end nodes, that may extend to LAN edge switch.

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

o S4: now divided into sub-sections

o S4.1: Admission control: added second proposed method for how to
decide to block new 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 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 of "partially PCN-capable tunnel" and
degraded bullet on this in S6 (Open Issues)

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

o S8: Operations and Management: substantially revised.

o other minor changes not affecting semantics

Eardley (Editor) Expires January 15, 2009 [Page 38]

Internet-Draft Document July 2008

15.4. 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)

o S1: Benefits: clarified that the objective is 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 network and not at ingress of PCN-domain (assume trust
between networks)

o S1: Deployment models: corrected MPLS-TE to MPLS

o S2: Terminology: adjusted definition of PCN-domain

o S3.5: Other assumptions: corrected, so that two assumptions (PCN-
nodes not performing ECN and PCN-ingress-node discarding arriving
CE packet) only apply if the PCN WG decides to encode PCN-marking
in the ECN-field.

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

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

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

o S5: clarified to say that PCN functionality is done on an
'interface' (rather than on a 'link')

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

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

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

Eardley (Editor) Expires January 15, 2009 [Page 39]

Internet-Draft Document July 2008

PCN-egress-node.

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

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

o S6: Open issues: added one about scenarios with only one tunnel
endpoint in the PCN domain .

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

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

o S10: Conclusions: a small conclusions section added

16. Appendix A: Possible work items beyond the scope of the current PCN
WG Charter

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's not standardised.

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

The first set of possibilities relate to the restrictions on scope
imposed by the PCN WG Charter (see Section 3):

o a single PCN-domain encompasses several autonomous systems that
don't trust each other (perhaps by using a mechanism like re-ECN,
[I-D.briscoe-re-pcn-border-cheat].

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 the of the good QoS on the
virtual link (the tunnel). Another example is that PCN
functionality needs to be configured consistently is

Eardley (Editor) Expires January 15, 2009 [Page 40]

Internet-Draft Document July 2008

deployed on either the
ingress or general Internet (ie widely but not universally
deployed).

o applying the egress interface PCN mechanisms to other types of PCN-nodes in a PCN-domain.

o S5.2: clarified 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 signalling protocol installs flow filter spec
at PCN-ingress-node (& updates after possible re-route)

o S5.6: addressing: clarified adapts according to the pre-congestion information.

o S5.7: added tunnelling issue of N^2 scaling if you set up a mesh
of tunnels between PCN-boundary-nodes the aggregation assumption doesn't hold, because the link capacity
is too low. Measurement-based admission control is then risky.

o S7.3: Clarified the "third viewpoint" applicability of probing (always probe). PCN mechanisms for emergency use (911, GETS,
WPS, MLPP, etc.)

Other possibilities include:

o S8.1: clarified that SNMP The PCN-domain extends to the end users. The scenario is only an example; added note that an
operator may be able
described in [I-D.babiarz-pcn-sip-cap]. The end users need 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 possible
trusted to have different PCN-boundary-node
behaviours for different ingress-egress-aggregates within the same
PCN-domain.

o Appendix: Created an Appendix about "Possible work items beyond do their own policing. This scenario is in the scope
of the current PCN WG Charter". Material moved from
near start charter if there is sufficient traffic for the
aggregation assumption to hold. A variant is that the PCN-domain
extends out as far as the LAN edge switch.

o indicating pre-congestion through signalling messages rather than
in-band (in the form of S3 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 elsewhere throughout draft. Moved text about that the centralised node signals to the PCN-ingress-
node about the decision about admission (or termination). It may
also need the centralised node and the PCN-boundary-nodes to Appendix.

o Other minor clarifications.

14.2. Changes from -01 know
each other's addresses. It would be possible for the centralised
node to -02

o S1: Benefits: provisioning bullet extended be one of the PCN-boundary-nodes, when clearly the
signalling would sometimes be replaced by a message internal to stress that PCN does
not use RFC2475-style traffic conditioning.
the node.

o S1: Deployment models: mentioned, as variant 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
PCN-boundary-node ([I-D.briscoe-tsvwg-cl-architecture] considers
what happens if RSVP is the QoS signalling protocol); establishing
a tunnel across the PCN-domain
extending to end nodes, that may extend if it is necessary to LAN edge switch. carry ECN
marks transparently. Note: There is a PCN WG Milestone on
"Requirements for signalling", which is potential input for the

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 39] 41]

Internet-Draft Document February July 2008

appropriate WGs.

o S3.1: Trust Assumption: added note about Policing by the PCN-ingress-node may not needing PCN-marking
capability be needed if known the PCN-
domain can trust that an interface cannot become pre-congested. the upstream network has already policed the
traffic on its behalf.

o S4: now divided into sub-sections PCN for Pseudowire: PCN may be used as a congestion avoidance
mechanism for edge to edge pseudowire emulations
[I-D.ietf-pwe3-congestion-frmwk].

o S4.1: Admission control: added second proposed method PCN for MPLS: [RFC3270] defines how to
decide to block new flows (PCN-egress-node receives one (or
several) PCN-marked packets).

o S5: Probing sub-section removed. Material now support the DiffServ
architecture in new S7.

o S5.6: Addressing: clarified MPLS networks. [RFC5129] describes how PCN-ingress-node can discover
address of PCN-egress-node

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

o S5.8: Tunnelling: added case microflows into a set of "partially PCN-capable tunnel" and
degraded bullet on this MPLS aggregates
(Multi-protocol label switching). PCN-marking is done in S6 (Open Issues)

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

o S8: Operations and Management: substantially revised. MPLS's
EXP field (which [I-D.andersson-mpls-expbits-def] proposes to re-
name to the Class of Service (CoS) bits).

o other minor changes not affecting semantics

14.3. Changes from -00 PCN for Ethernet: Similarly, it may be possible to -01

In addition 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.

17. Appendix B: Probing

17.1. Introduction

Probing is an optional mechanism to clarifications and nit squashing, assist admission control.

PCN's admission control, as described so far, is essentially a
reactive mechanism where the main changes
are:

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

o S1: Benefits: clarified 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 objective PCN-egress-node can't make an admission decision
using the usual method described earlier.

One approach is 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 network be "optimistic" and not at ingress of PCN-domain (assume trust
between networks)

o S1: Deployment models: corrected MPLS-TE simply admit the new flow.
However it's possible to MPLS

o S2: Terminology: adjusted definition of PCN-domain

o S3.5: Other assumptions: corrected, envisage a scenario where the traffic levels
on other ingress-egress-aggregates are already so high that two assumptions (PCN-
nodes not performing ECN they're
blocking new PCN-flows, and PCN-ingress-node discarding arriving admitting a new flow onto this 'empty'
ingress-egress-aggregate adds extra traffic onto the link that's
already pre-congested - which may 'tip the balance' so that PCN's
flow termination mechanism is activated or some packets are dropped.
This risk could be lessened by configuring on each link sufficient
'safety margin' above the PCN-threshold-rate.

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 40] 42]

Internet-Draft Document February July 2008

CE packet) only apply if

An alternative approach is to make PCN a more proactive mechanism.
The PCN-ingress-node explicitly determines, before admitting the PCN WG decides to encode PCN-marking
prospective new flow, whether the ingress-egress-aggregate can
support it. This can be seen as a "pessimistic" approach, in
contrast to the ECN-field.

o S4 & S5: changed PCN-marking algorithm "optimism" of the approach above. It involves
probing: a PCN-ingress-node generates and sends probe packets in
order to marking behaviour

o S4: clarified test the pre-congestion level that PCN-interior-node functionality applies for
each outgoing interface, and added clarification: "The
functionality the flow would
experience.

One possibility is also done that a probe packet is just a dummy data packet,
generated by PCN-ingress-nodes for their outgoing
interfaces (ie those 'inside' the PCN-domain)."

o S4 (near end): altered PCN-ingress-node and addressed to say the PCN-egress-
node. Another possibility is that a PCN-node "should" dedicate
some capacity to lower priority traffic so that it isn't starved
(was "may")

o S5: clarified to say that PCN functionality probe packet is done on an
'interface' (rather than on a 'link')

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

o S5.5: Probing: re-written, especially to distinguish probing signalling
packet that is anyway travelling from the PCN-ingress-node to
test the ingress-egress-aggregate
PCN-egress-node (eg an RSVP PATH message travelling from probing source to test a
particular ECMP path.
destination).

17.2. Probing functions

The probing functions are:

o S5.7: Addressing: added mention of probing; added Make decision that in probing is needed. As described above, this is
when the case
where traffic ingress-egress-aggregate (or the ECMP path - Section 8)
carries no PCN-traffic. An alternative is always tunnelled across to probe, ie
probe before admitting every PCN-flow.

o (if required) Communicate the request that probing is needed - the PCN-domain, add a
note
PCN-egress-node signals to the PCN-ingress-node that he probing is
needed

o (if required) Generate probe traffic - the PCN-ingress-node needs to know
generates the address probe traffic. The appropriate number (or rate) of
probe packets will depend on the
PCN-egress-node.

o S5.8: Tunnelling: re-written, especially to provide PCN-marking algorithm; for
example an excess-traffic-marking algorithm generates fewer PCN-
marks than a clearer
description of copying on tunnel entry/exit, by adding explanation
(keeping tunnel encaps/decaps threshold-marking algorithm, and PCN-marking orthogonal),
deleting one bullet ("if the inner header's marking state is so will need more
sever then it is preserved" - shouldn't happen), and better
referencing of other IETF documents.
probe packets.

o S6: Open issues: stressed that "NOTE: Potential solutions Forward probe packets - as far as PCN-interior-nodes are out
concerned, probe packets are handled the same as (ordinary data)
PCN-packets, in terms of scope for this document" routing, scheduling and edited a couple of sentences that
were close to solution space. PCN-marking.

o S6: Open issues: added one about scenarios with only one tunnel
endpoint in Consume probe packets - the PCN domain .

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

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

Eardley (Editor) Expires August 11, 2008 [Page 41]

Internet-Draft Document February 2008

o S10: Conclusions: a small conclusions section added

15. Appendix A: Possible work items PCN-egress-node consumes probe packets
to ensure that they don't travel beyond the scope PCN-domain.

17.3. Discussion of the current PCN
WG Charter

This section mentions some topics that are outside the PCN WG's
current Charter, rationale for probing, its downsides and open
issues

It is an unresolved question whether probing is really needed, but which
three viewpoints have been mentioned put forward 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's not standardised.

NOTE: to why it should be crystal clear that this section discusses
possibilities only. is useful. The

Eardley (Editor) Expires January 15, 2009 [Page 43]

Internet-Draft Document July 2008

first set of possibilities relate to is perhaps the restrictions most obvious: there is no PCN-traffic on scope
imposed by the PCN WG Charter (see Section 3):

o a single PCN-domain encompasses several autonomous systems
ingress-egress-aggregate. The second assumes that
don't trust each other (perhaps multipath routing
ECMP is running in the PCN-domain. The third viewpoint is that
admission control is always done by using probing. We now consider each in
turn.

The first viewpoint assumes the following:

o There is no PCN-traffic on the ingress-egress-aggregate (so a mechanism like re-ECN,
[I-D.briscoe-re-pcn-border-cheat].
normal admission decision cannot be made).

o not all Simply admitting the nodes run PCN. For example, new flow has a significant risk of leading to
overload: packets dropped or flows terminated.

On the PCN-domain is former bullet, [PCN-email-traffic-empty-aggregates] suggests
that, during the future busy hour of a
multi-site enterprise network. The sites national network with about
100 PCN-boundary-nodes, there are connected by likely to be significant numbers of
aggregates with very few flows under nearly all circumstances.

The latter bullet could occur if a VPN
tunnel; although PCN doesn't operate inside the tunnel, the PCN
mechanisms still work properly because the new flow starts on many of the good QoS
empty ingress-egress-aggregates and causes overload on the
virtual a link (the tunnel). Another example is that PCN is
deployed on the general Internet (ie widely but not universally
deployed).

o applying in the PCN mechanisms
PCN-domain. To be a problem this would probably have to other types of traffic, ie beyond
inelastic traffic. For instance, applying happen in a
short time period (flash crowd) because, after the PCN mechanisms to
traffic scheduled with reaction time of
the Assured Forwarding per-hop behaviour.
One example could be flow-rate adaptation by elastic applications, system, other (non-empty) ingress-egress-aggregates that adapts according to pass
through the link will measure pre-congestion information. and so block new flows,
and also flows naturally end anyway.

The downsides of probing for this viewpoint are:

o Probing adds delay to the aggregation assumption doesn't hold, because the link capacity
is too low. Measurement-based admission control is then risky. process.

o Sufficient probing traffic has to be generated to test the applicability pre-
congestion level of PCN mechanisms for emergency use (911, GETS,
WPS, MLPP, etc.)

Other possibilities the ingress-egress-aggregate. But the probing
traffic itself may cause pre-congestion, causing other PCN-flows
to be blocked or even terminated - and in the flash crowd scenario
there will be probing on many ingress-egress-aggregates.

The open issues associated with this viewpoint include:

o indicating pre-congestion through signalling messages rather than
in-band (in What rate and pattern of probe packets does the form PCN-ingress-node
need to generate, so that there's enough traffic to make the
admission decision?

o What difficulty does the delay (whilst probing is done) cause
applications, eg packets might be dropped?

o Are there other ways of PCN-marked packets) dealing with the flash crowd scenario?
For instance limit the rate at which new flows are admitted; or

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 42] 44]

Internet-Draft Document February July 2008

perhaps for a PCN-egress-node to block new flows on its empty
ingress-egress-aggregates when its non-empty ones are pre-
congested.

The second viewpoint applies in the decision-making functionality case where there is at a centralised node rather
than at multipath
routing (ECMP) in the PCN-boundary-nodes. This requires 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 PCN-
egress-node signals PCN-feedback-information to ingress-
egress-aggregate, then the centralised
node, and viewpoint that probing is useful assumes:

o there's a significant chance that the centralised node signals to the PCN-ingress-
node about the decision about admission (or termination). It may
also need traffic is unevenly balanced
across the centralised node ECMP paths, and the PCN-boundary-nodes to know
each others addresses. It would hence there's a significant risk of
admitting a flow that should be possible for the centralised
node to blocked (because it follows an
ECMP path that is pre-congested) or blocking a flow that should be one
admitted.

o Note: [PCN-email-ECMP] suggests unbalanced traffic is quite
possible, even with quite a large number of the PCN-boundary-nodes, when clearly the
signalling would sometimes be replaced by flows on a message internal PCN-link
(eg 1000) when Assumption 3 (aggregation) is likely to be
satisfied.

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

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

o It would be possible for Simply admitting the centralised node to be one new flow has a significant risk of the
PCN-boundary-nodes, when clearly the signalling would sometimes be
replaced by leading to
overload.

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

o signalling extensions for specific protocols (eg RSVP, NSIS). For
example: the details of how the signalling protocol installs the
flowspec at Note: This is similar to the PCN-ingress-node for an admitted PCN-flow; first viewpoint and how
the signalling protocol carries the PCN-feedback-information.
Perhaps also for other functions such as: coping with failure of so similarly
could occur in a
PCN-boundary-node ([I-D.briscoe-tsvwg-cl-architecture] considers
what happens flash crowd if RSVP a new flow starts more-or-less
simultaneously on many of the empty ECMP paths. Because there are
several (sometimes many) ECMP paths between each pair of PCN-
boundary-nodes, it's presumably more likely that an ECMP path is
'empty' than an ingress-egress-aggregate. To constrain the QoS signalling protocol); establishing number
of ECMP paths, a tunnel across few tunnels could be set-up between each pair of
PCN-boundary-nodes. Tunnelling also solves the PCN-domain if it third bullet
(which is necessary to carry ECN
marks transparently. Note: There otherwise hard because an ECMP routing decision is a PCN WG Milestone made
independently on
"Requirements for signalling", which is potential input each node).

The downsides of probing for the
appropriate WGs. this viewpoint are:

Eardley (Editor) Expires January 15, 2009 [Page 45]

Internet-Draft Document July 2008

o policing by Probing adds delay to the PCN-ingress-node may not admission control process.

o Sufficient probing traffic has to be needed if generated to test the PCN-
domain can trust that pre-
congestion level of the upstream network has already policed ECMP path. But there's the risk that the
probing traffic on its behalf.

o PCN for Pseudowire: PCN itself may be used as a congestion avoidance
mechanism for edge cause pre-congestion, causing other
PCN-flows to edge pseudowire emulations
[I-D.ietf-pwe3-congestion-frmwk]. be blocked or even terminated.

o PCN for MPLS: [RFC3270] defines how The PCN-egress-node needs to support consume the DiffServ
architecture in MPLS networks. [RFC5129] describes how probe packets to add PCN
for admission control of microflows into ensure
they don't travel beyond the PCN-domain (eg they might confuse the
destination end node). Hence somehow the PCN-egress-node has to
be able to disambiguate a set probe packet from a data packet, via the
characteristic setting of MPLS aggregates
(Multi-protocol label switching). PCN-marking is done particular bit(s) in MPLS's
EXP field.

o PCN for Ethernet: Similarly, the packet's header
or body - but these bit(s) mustn't be used by any PCN-interior-
node's ECMP algorithm. In the general case this isn't possible,
but it may should be possible to extend PCN into
Ethernet networks, where OK for a typical ECMP algorithm which examines:
the source and destination IP addresses and port numbers, the
protocol ID and the DSCP.

The third viewpoint assumes the following:

o Every admission control decision involves probing, using the
signalling set-up message as the probe packet (eg RSVP PATH).

o The PCN-marking behaviour is done such that every packet is PCN-marked
if the flow should be blocked, hence only a single probing packet
is needed.

This viewpoint [I-D.draft-babiarz-pcn-3sm] has in particular been
suggested for the Ethernet
header.

Eardley (Editor) Expires August 11, 2008 [Page 43]

Internet-Draft Document February 2008

16. scenario where the PCN-domain reaches out towards
the end terminals (note that it's assumed the trust and aggregation
assumptions still hold), although it has also been suggested for
other scenarios.

18. Informative References

[I-D.briscoe-tsvwg-cl-architecture]
Briscoe, B., "An edge-to-edge Deployment Model for Pre-
Congestion Notification: Admission Control over a
DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04
(work in progress), October 2006.

[I-D.briscoe-tsvwg-cl-phb]
Briscoe, B., "Pre-Congestion Notification marking",
draft-briscoe-tsvwg-cl-phb-03 (work in progress),
October 2006.

[I-D.babiarz-pcn-sip-cap]

Eardley (Editor) Expires January 15, 2009 [Page 46]

Internet-Draft Document July 2008

Babiarz, J., "SIP Controlled Admission and Preemption",
draft-babiarz-pcn-sip-cap-00 (work in progress),
October 2006.

[I-D.lefaucheur-rsvp-ecn]
Faucheur, F., "RSVP Extensions for Admission Control over
Diffserv using Pre-congestion Notification (PCN)",
draft-lefaucheur-rsvp-ecn-01 (work in progress),
June 2006.

[I-D.chan-pcn-problem-statement]
Chan, K., "Pre-Congestion Notification Problem Statement",
draft-chan-pcn-problem-statement-01 (work in progress),
October 2006.

[I-D.ietf-pwe3-congestion-frmwk]
Bryant, S.,
"Pseudowire Congestion Control Framework",
draft-ietf-pwe3-congestion-frmwk-00 (work in progress),
February 2007.

[I-D.ietf-tsvwg-admitted-realtime-dscp]
"DSCPs for Capacity-Admitted Traffic", November 2006, <htt
p://www.ietf.org/internet-drafts/
ietf-tsvwg-admitted-realtime-dscp-02.txt>. May 2008, <http
://www.ietf.org/internet-drafts/
draft-ietf-pwe3-congestion-frmwk-01.txt>.

[I-D.briscoe-tsvwg-ecn-tunnel]
"Layered Encapsulation of Congestion Notification",
June 2007,
July 2008, <http://www.ietf.org/internet-drafts/
briscoe-tsvwg-ecn-tunnel-00.txt>.
briscoe-tsvwg-ecn-tunnel-01.txt>.

[I-D.charny-pcn-single-marking]
"Pre-Congestion Notification Using Single Marking for
Admission and Termination", November 2007, <http://
www.ietf.org/internet-drafts/

Eardley (Editor) Expires August 11, 2008 [Page 44]

Internet-Draft Document February 2008
draft-charny-pcn-single-marking-03.txt>.

[I-D.eardley-pcn-architecture]
"Pre-Congestion Notification Architecture", June 2007, <ht
tp://www.ietf.org/internet-drafts/
draft-eardley-pcn-architecture-00.txt>.

[I-D.westberg-pcn-load-control]
"LC-PCN: The Load Control PCN Solution", November 2007, February 2008, <h
ttp://www.ietf.org/internet-drafts/
draft-westberg-pcn-load-control-02.txt>.
draft-westberg-pcn-load-control-03.txt>.

[I-D.behringer-tsvwg-rsvp-security-groupkeying]
"Applicability of Keying Methods for RSVP Security",
November 2007, <http://www.watersprings.org/pub/id/
draft-behringer-tsvwg-rsvp-security-groupkeying-01.txt>.

[I-D.briscoe-re-pcn-border-cheat]
"Emulating Border Flow Policing using Re-ECN on Bulk

Eardley (Editor) Expires January 15, 2009 [Page 47]

Internet-Draft Document July 2008

Data", June 2006, <http://www.watersprings.org/pub/id/
briscoe-re-pcn-border-cheat-01.txt>. February 2008, <http://tools.ietf.org/id/
draft-briscoe-re-pcn-border-cheat-01.txt>.

[I-D.draft-babiarz-pcn-3sm]
"Three State PCN Marking", November 2007, <http://
www.watersprings.org/pub/id/draft-babiarz-pcn-3sm-01.txt>.

[RFC5129] "Explicit Congestion Marking in MPLS", RFC 5129,
January 2008.

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

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, 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.

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

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

Eardley (Editor) Expires August 11, 2008 [Page 45]

Internet-Draft Document February 2008

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

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

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

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

[RFC2983] Black, D., "Differentiated Services and Tunnels",

Eardley (Editor) Expires January 15, 2009 [Page 48]

Internet-Draft Document July 2008

RFC 2983, October 2000.

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

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

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

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

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
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.

[ITU-MLPP]
"Multilevel Precedence and Pre-emption Service (MLPP)",
ITU-T Recommendation I.255.3, 1990.

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

Eardley (Editor) Expires August 11, 2008 [Page 46]

Internet-Draft Document February 2008

[Shenker] "Fundamental design issues for the future Internet", IEEE
Journal on selected areas in communications pp 1176 -
1188, Vol 13 (7), 1995.

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

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

[Songhurst]
"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/

Eardley (Editor) Expires January 15, 2009 [Page 49]

Internet-Draft Document July 2008

projects/ipe2eqos/gqs/papers/GQS_shared_tr.pdf>.

[Menth] "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>.

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

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

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

[I-D.eardley-pcn-marking-behaviour]
"Marking behaviour of PCN-nodes", June 2008, <http://
www.ietf.org/internet-drafts/
draft-eardley-pcn-marking-behaviour-01.txt>.

[I-D.moncaster-pcn-baseline-encoding]
"Baseline Encoding and Transport of Pre-Congestion
Information", July 2008, <http://www.ietf.org/
internet-drafts/
draft-moncaster-pcn-baseline-encoding-02.txt>.

[I-D.moncaster-pcn-3-state-encoding]
"A three state extended PCN encoding scheme", June 2008, <
http://www.ietf.org/internet-drafts/
draft-moncaster-pcn-3-state-encoding-00.txt>.

[I-D.charny-pcn-comparison]
"Pre-Congestion Notification Using Single Marking for
Admission and Termination", November 2007, <http://
www.watersprings.org/pub/id/
draft-charny-pcn-comparison-00.txt>.

[I-D.tsou-pcn-racf-applic]
"Applicability Statement for the Use of Pre-Congestion
Notification in a Resource-Controlled Network",
February 2008, <http://tools.ietf.org/id/
draft-tsou-pcn-racf-applic-00.txt>.

[I-D.sarker-pcn-ecn-pcn-usecases]

Eardley (Editor) Expires January 15, 2009 [Page 50]

Internet-Draft Document July 2008

"Usecases and Benefits of end to end ECN support in PCN
Domains", May 2008, <http://tools.ietf.org/id/
draft-sarker-pcn-ecn-pcn-usecases-01.txt>.

[I-D.andersson-mpls-expbits-def]
"MPLS EXP-bits definition", March 2008, <http://
tools.ietf.org/id/
draft-andersson-mpls-expbits-def-00.txt>.

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

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

Author's Address

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 August 11, 2008 January 15, 2009 [Page 47] 51]

Internet-Draft Document February July 2008

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

Eardley (Editor) Expires August 11, 2008 January 15, 2009 [Page 48] 52]

----