draft-ietf-pcn-architecture-02.txt   draft-ietf-pcn-architecture-03.txt 
Congestion and Pre-Congestion Philip. Eardley (Editor) Congestion and Pre-Congestion Philip. Eardley (Editor)
Notification Working Group BT Notification Working Group BT
Intended status: Informational Intended status: Informational
Expires: May 22, 2008 Expires: August 11, 2008
Pre-Congestion Notification Architecture Pre-Congestion Notification Architecture
draft-ietf-pcn-architecture-02 draft-ietf-pcn-architecture-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008. This Internet-Draft will expire on August 11, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The purpose of this document is to describe a general architecture The purpose of this document is to describe a general architecture
for flow admission and termination based on aggregated pre-congestion for flow admission and termination based on pre-congestion
information in order to protect the quality of service of established information in order to protect the quality of service of established
inelastic flows within a single DiffServ domain. inelastic flows within a single DiffServ domain.
Status Status
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Assumptions and constraints on scope . . . . . . . . . . . . . 9 3. Assumptions and constraints on scope . . . . . . . . . . . . . 9
3.1. Assumption 1: Trust - controlled environment . . . . . . . 10 3.1. Assumption 1: Trust and support of PCN - controlled
environment . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Assumption 2: Real-time applications . . . . . . . . . . . 10 3.2. Assumption 2: Real-time applications . . . . . . . . . . . 10
3.3. Assumption 3: Many flows and additional load . . . . . . . 11 3.3. Assumption 3: Many flows and additional load . . . . . . . 10
3.4. Assumption 4: Emergency use out of scope . . . . . . . . . 11 3.4. Assumption 4: Emergency use out of scope . . . . . . . . . 11
3.5. Other assumptions . . . . . . . . . . . . . . . . . . . . 11 3.5. Other assumptions . . . . . . . . . . . . . . . . . . . . 11
4. High-level functional architecture . . . . . . . . . . . . . . 12 4. High-level functional architecture . . . . . . . . . . . . . . 11
4.1. Flow admission . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Flow admission . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Flow termination . . . . . . . . . . . . . . . . . . . . . 13 4.2. Flow termination . . . . . . . . . . . . . . . . . . . . . 13
4.3. Flow admission and flow termination . . . . . . . . . . . 14 4.3. Flow admission and flow termination . . . . . . . . . . . 14
4.4. Information transport . . . . . . . . . . . . . . . . . . 15 4.4. Information transport . . . . . . . . . . . . . . . . . . 15
4.5. PCN-traffic . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. PCN-traffic . . . . . . . . . . . . . . . . . . . . . . . 15
5. Detailed Functional architecture . . . . . . . . . . . . . . . 16 5. Detailed Functional architecture . . . . . . . . . . . . . . . 16
5.1. PCN-interior-node functions . . . . . . . . . . . . . . . 17 5.1. PCN-interior-node functions . . . . . . . . . . . . . . . 17
5.2. PCN-ingress-node functions . . . . . . . . . . . . . . . . 17 5.2. PCN-ingress-node functions . . . . . . . . . . . . . . . . 17
5.3. PCN-egress-node functions . . . . . . . . . . . . . . . . 18 5.3. PCN-egress-node functions . . . . . . . . . . . . . . . . 18
5.4. Admission control functions . . . . . . . . . . . . . . . 18 5.4. Other admission control functions . . . . . . . . . . . . 19
5.5. Flow termination functions . . . . . . . . . . . . . . . . 19 5.5. Other flow termination functions . . . . . . . . . . . . . 19
5.6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20 5.6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20
5.7. Tunnelling . . . . . . . . . . . . . . . . . . . . . . . . 21 5.7. Tunnelling . . . . . . . . . . . . . . . . . . . . . . . . 21
5.8. Fault handling . . . . . . . . . . . . . . . . . . . . . . 22 5.8. Fault handling . . . . . . . . . . . . . . . . . . . . . . 22
6. Design goals and challenges . . . . . . . . . . . . . . . . . 23 6. Design goals and challenges . . . . . . . . . . . . . . . . . 23
7. Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 25 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 25
7.2. Probing functions . . . . . . . . . . . . . . . . . . . . 26 7.2. Probing functions . . . . . . . . . . . . . . . . . . . . 26
7.3. Discussion of rationale for probing, its downsides and 7.3. Discussion of rationale for probing, its downsides and
open issues . . . . . . . . . . . . . . . . . . . . . . . 27 open issues . . . . . . . . . . . . . . . . . . . . . . . 27
8. Operations and Management . . . . . . . . . . . . . . . . . . 30 8. Operations and Management . . . . . . . . . . . . . . . . . . 30
8.1. Configuration OAM . . . . . . . . . . . . . . . . . . . . 30 8.1. Configuration OAM . . . . . . . . . . . . . . . . . . . . 30
8.1.1. System options . . . . . . . . . . . . . . . . . . . . 30 8.1.1. System options . . . . . . . . . . . . . . . . . . . . 31
8.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . . 31 8.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . . 31
8.2. Performance & Provisioning OAM . . . . . . . . . . . . . . 33 8.2. Performance & Provisioning OAM . . . . . . . . . . . . . . 33
8.3. Accounting OAM . . . . . . . . . . . . . . . . . . . . . . 34 8.3. Accounting OAM . . . . . . . . . . . . . . . . . . . . . . 34
8.4. Fault OAM . . . . . . . . . . . . . . . . . . . . . . . . 34 8.4. Fault OAM . . . . . . . . . . . . . . . . . . . . . . . . 34
8.5. Security OAM . . . . . . . . . . . . . . . . . . . . . . . 35 8.5. Security OAM . . . . . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
10. Security considerations . . . . . . . . . . . . . . . . . . . 36 10. Security considerations . . . . . . . . . . . . . . . . . . . 36
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 37
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
13. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 38 13. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 38
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
15. Informative References . . . . . . . . . . . . . . . . . . . . 40 14.1. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 14.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 45 14.3. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 40
15. Appendix A: Possible work items beyond the scope of the
current PCN WG Charter . . . . . . . . . . . . . . . . . . . . 42
16. Informative References . . . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 48
1. Introduction 1. Introduction
The purpose of this document is to describe a general architecture The purpose of this document is to describe a general architecture
for flow admission and termination based on aggregated (pre-) for flow admission and termination based on (pre-) congestion
congestion information in order to protect the quality of service of information in order to protect the quality of service of flows
flows within a DiffServ domain [RFC2475]. This document defines an within a DiffServ domain [RFC2475]. This document defines an
architecture for implementing two mechanisms to protect the quality architecture for implementing two mechanisms to protect the quality
of service of established inelastic flows within a single DiffServ of service of established inelastic flows within a single DiffServ
domain, where all boundary and interior nodes are PCN-enabled and domain, where all boundary and interior nodes are PCN-enabled and
trust each other for correct PCN operation. Flow admission control trust each other for correct PCN operation. Flow admission control
determines whether a new flow should be admitted and protects the QoS determines whether a new flow should be admitted, in order to protect
of existing PCN-flows in normal circumstances, by avoiding congestion the QoS of existing PCN-flows in normal circumstances. However, in
occurring. However, in abnormal circumstances, for instance a abnormal circumstances, for instance a disaster affecting multiple
disaster affecting multiple nodes and causing traffic re-routes, then nodes and causing traffic re-routes, then the QoS on existing PCN-
the QoS on existing PCN-flows may degrade even though care was flows may degrade even though care was exercised when admitting those
exercised when admitting those flows before those circumstances. flows before those circumstances. Therefore we also propose a
Therefore we also propose a mechanism for flow termination, which mechanism for flow termination, which removes enough traffic in order
removes enough traffic in order to protect the QoS of the remaining to protect the QoS of the remaining PCN-flows.
PCN-flows.
As a fundamental building block to enable these two mechanisms, PCN- As a fundamental building block to enable these two mechanisms, PCN-
interior-nodes generate, encode and transport pre-congestion interior-nodes generate, encode and transport pre-congestion
information towards the PCN-egress-nodes. Two rates, a PCN-lower- information towards the PCN-egress-nodes. Two rates, a PCN-lower-
rate and a PCN-upper-rate, can be associated with each link of the rate and a PCN-upper-rate, can be associated with each link of the
PCN-domain. Each rate is used by a marking behaviour (specified in PCN-domain. Each rate is used by a marking behaviour (specified in
another document) that determines how and when a number of PCN- another document) that determines how and when a number of PCN-
packets are marked, and how the markings are encoded in packet packets are marked, and how the markings are encoded in packet
headers. PCN-egress-nodes make measurements of the packet markings headers. PCN-egress-nodes make measurements of the packet markings
and send information as necessary to the nodes that make the decision and send information as necessary to the nodes that make the decision
skipping to change at page 5, line 11 skipping to change at page 5, line 11
so on. It is not generally required that other network entities so on. It is not generally required that other network entities
are aware of individual flows (although they may be in particular are aware of individual flows (although they may be in particular
deployment scenarios). deployment scenarios).
o Admission control is resilient: PCN's QoS is decoupled from the o Admission control is resilient: PCN's QoS is decoupled from the
routing system; hence in general admitted flows can survive routing system; hence in general admitted flows can survive
capacity, routing or topology changes without additional capacity, routing or topology changes without additional
signalling, and they don't have to be told (or learn) about such signalling, and they don't have to be told (or learn) about such
changes. The PCN-lower-rates can be chosen small enough that changes. The PCN-lower-rates can be chosen small enough that
admitted traffic can still be carried after a rerouting in most admitted traffic can still be carried after a rerouting in most
failure cases. This is an important feature as QoS violations in failure cases [Menth]. This is an important feature as QoS
core networks due to link failures are more likely than QoS violations in core networks due to link failures are more likely
violations due to increased traffic volume [Iyer]. than QoS violations due to increased traffic volume [Iyer].
o The PCN-marking behaviours only operate on the overall PCN-traffic o The PCN-marking behaviours only operate on the overall PCN-traffic
on the link, not per flow. on the link, not per flow.
o The information of these measurements is signalled to the PCN- o The information of these measurements is signalled to the PCN-
egress-nodes by the PCN-marks in the packet headers. No egress-nodes by the PCN-marks in the packet headers, ie "in-band".
additional signalling protocol is required for transporting the No additional signalling protocol is required for transporting the
PCN-marks. Therefore no secure binding is required between data PCN-marks. Therefore no secure binding is required between data
packets and separate congestion messages. packets and separate congestion messages.
o The PCN-egress-nodes make separate measurements, operating on the o The PCN-egress-nodes make separate measurements, operating on the
overall PCN-traffic, for each PCN-ingress-node, ie not per flow. aggregate PCN-traffic from each PCN-ingress-node, ie not per flow.
Similarly, signalling by the PCN-egress-node of PCN-feedback- Similarly, signalling by the PCN-egress-node of PCN-feedback-
information (which is used for flow admission and termination information (which is used for flow admission and termination
decisions) is at the granularity of the ingress-egress-aggregate. decisions) is at the granularity of the ingress-egress-aggregate.
An alternative approach is that the PCN-egress-nodes monitor the
PCN-traffic and signal PCN-feedback-information (which is used for
flow admission and termination decisions) at the granularity of
one (or a few) PCN-marks.
o The admitted PCN-load is controlled dynamically. Therefore it o The admitted PCN-load is controlled dynamically. Therefore it
adapts as the traffic matrix changes, and also if the network adapts as the traffic matrix changes, and also if the network
topology changes (eg after a link failure). Hence an operator can topology changes (eg after a link failure). Hence an operator can
be less conservative when deploying network capacity, and less be less conservative when deploying network capacity, and less
accurate in their prediction of the PCN-traffic matrix. accurate in their prediction of the PCN-traffic matrix.
o The termination mechanism complements admission control. It o The termination mechanism complements admission control. It
allows the network to recover from sudden unexpected surges of allows the network to recover from sudden unexpected surges of
PCN-traffic on some links, thus restoring QoS to the remaining PCN-traffic on some links, thus restoring QoS to the remaining
skipping to change at page 6, line 11 skipping to change at page 6, line 13
termination of some PCN-flows before loss (or excessive delay) of termination of some PCN-flows before loss (or excessive delay) of
PCN-packets occurs, or to keep the maximum PCN-load on a link PCN-packets occurs, or to keep the maximum PCN-load on a link
below a level configured by the operator. below a level configured by the operator.
o Provisioning of the network is decoupled from the process of o Provisioning of the network is decoupled from the process of
adding new customers. By contrast, with the DiffServ architecture adding new customers. By contrast, with the DiffServ architecture
[RFC2475] operators rely on subscription-time Service Level [RFC2475] operators rely on subscription-time Service Level
Agreements that statically define the parameters of the traffic Agreements that statically define the parameters of the traffic
that will be accepted from a customer, and so the operator has to that will be accepted from a customer, and so the operator has to
run the provisioning process each time a new customer is added to run the provisioning process each time a new customer is added to
check that the Service Level Agreement can be fulfilled. PCN does check that the Service Level Agreement can be fulfilled. A PCN-
not use RFC2475-style traffic conditioning. domain doesn't need such traffic conditioning.
Operators of networks will want to use the PCN mechanisms in various Operators of networks will want to use the PCN mechanisms in various
arrangements, for instance depending on how they are performing arrangements, for instance depending on how they are performing
admission control outside the PCN-domain (users after all are admission control outside the PCN-domain (users after all are
concerned about QoS end-to-end), what their particular goals and concerned about QoS end-to-end), what their particular goals and
assumptions are, and so on. Several deployment models are possible: assumptions are, and so on. Several deployment models are possible:
o An operator may choose to deploy either admission control or flow o An operator may choose to deploy either admission control or flow
termination or both (see Section 4.3). termination or both (see Section 4.3).
o IntServ over DiffServ [RFC2998]. The DiffServ region is PCN- o IntServ over DiffServ [RFC2998]. The DiffServ region is PCN-
enabled, RSVP signalling is used end-to-end and the PCN-domain is enabled and the PCN-domain is a single RSVP hop, ie only the PCN-
a single RSVP hop, ie only the PCN-boundary-nodes process RSVP boundary-nodes process RSVP messages. Outside the PCN-domain RSVP
messages. Outside the PCN-domain RSVP messages are processed on messages are processed on each hop. The case where RSVP
each hop. This is described in signalling is used end-to-end is described in
[I-D.briscoe-tsvwg-cl-architecture] [I-D.briscoe-tsvwg-cl-architecture]; it would also be possible for
the RSVP signalling to be originated and/or terminated by proxies,
o RSVP signalling is originated and/or terminated by proxies, with with application-layer signalling between the end user and the
application-layer signalling between the end user and the proxy. proxy (eg SIP signalling with a home hub).
For instance SIP signalling with a home hub.
o Similar to previous bullets but NSIS signalling is used instead of o Similar to previous bullet but NSIS signalling is used instead of
RSVP. RSVP.
o NOTE: Consideration of signalling extensions for specific
protocols is outside the scope of the PCN WG, however it will
produce a "Requirements for signalling" document as potential
input for the appropriate WGs.
o Depending on the deployment scenario, the decision-making o Depending on the deployment scenario, the decision-making
functionality (about flow admission and termination) could reside functionality (about flow admission and termination) could reside
at the PCN-ingress-nodes or PCN-egress-nodes or at some central at the PCN-ingress-nodes or PCN-egress-nodes or (see Appendix) at
control node in the PCN-domain. NOTE: The Charter restricts us: some central control node in the PCN-domain.
the decision-making functionality is at the PCN-boundary-nodes.
o If the operator runs both the access network and the core network,
one deployment scenario is that only the core network uses PCN
admission control but per microflow policing is done at the
ingress to the access network and not at the PCN-ingress-node.
Note: to aid readability, the rest of this draft assumes that
policing is done by the PCN-ingress-nodes.
o There are several PCN-domains on the end-to-end path, each o There are several PCN-domains on the end-to-end path, each
operating PCN mechanisms independently. NOTE: The Charter operating PCN mechanisms independently.
restricts us to considering a single PCN-domain. A possibility
after re-chartering is to consider that the PCN-domain encompasses
several autonomous systems that don't trust each other (ie weakens
Assumption 1 about trust, see Section 3.1)
o The PCN-domain extends to the end users. NOTE: This isn't o The PCN-domain extends to the end users. The scenario is
necessarily outside the Charter because it may not break described in [I-D.babiarz-pcn-sip-cap]. A variant is that the
Assumption 3 (aggregation see later) if it's known there's PCN-domain extends out as far as the LAN edge switch.
sufficient aggregation at any bottleneck, and it doesn't
necessarily break Assumption 1 (trust), because in some o The operator runs both the access network (not a PCN-domain) and
environments, eg corporate, the end user may have a controlled the core network (a PCN-domain); per flow policing is devolved to
configuration and so be trusted. The scenario is described in the access network and is not done at the PCN-ingress-node. Note:
[I-D.babiarz-pcn-sip-cap]. A variant is that the PCN-domain to aid readability, the rest of this draft assumes that policing
extends out as far as the LAN edge switch. is done by the PCN-ingress-nodes.
o Pseudowire: PCN may be used as a congestion avoidance mechanism o Pseudowire: PCN may be used as a congestion avoidance mechanism
for edge to edge pseudowire emulations for edge to edge pseudowire emulations
[I-D.ietf-pwe3-congestion-frmwk]. NOTE: Specific consideration of [I-D.ietf-pwe3-congestion-frmwk].
pseudowires is not in the PCN WG Charter.
o MPLS: [RFC3270] defines how to support the DiffServ architecture o MPLS: [RFC3270] defines how to support the DiffServ architecture
in MPLS networks. [I-D.ietf-tsvwg-ecn-mpls] describes how to add in MPLS networks. [RFC5129] describes how to add PCN for
PCN for admission control of microflows into a set of MPLS admission control of microflows into a set of MPLS aggregates
aggregates (Multi-protocol label switching). PCN-marking is done (Multi-protocol label switching). PCN-marking is done in MPLS's
in MPLS's EXP field. EXP field.
o Similarly, it may be possible to extend PCN into Ethernet o Similarly, it may be possible to extend PCN into Ethernet
networks, where PCN-marking is done in the Ethernet header. NOTE: networks, where PCN-marking is done in the Ethernet header. NOTE:
Specific consideration of this extension is outside the IETF's Specific consideration of this extension is outside the IETF's
remit. remit.
From the perspective of the outside world, a PCN-domain essentially
looks like a DiffServ domain. PCN-traffic is either transported
across it transparently or policed at the PCN-ingress-node (ie
dropped or carried at a lower QoS). A couple of differences are
that: PCN-traffic has better QoS guarantees than normal DiffServ
traffic (because PCN's mechanisms better protect the QoS of admitted
flows); 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 is treated transparently, ie
the PCN-domain is a normal DiffServ domain.
2. Terminology 2. Terminology
o PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled o PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled
nodes that perform DiffServ scheduling; the compete set of PCN- nodes that perform DiffServ scheduling; the compete set of PCN-
nodes whose PCN-marking can in principle influence decisions about nodes whose PCN-marking can in principle influence decisions about
flow admission and termination for the PCN-domain, including the flow admission and termination for the PCN-domain, including the
PCN-egress-nodes which measure these PCN-marks. PCN-egress-nodes which measure these PCN-marks.
o PCN-boundary-node: a PCN-node that connects one PCN-domain to a o PCN-boundary-node: a PCN-node that connects one PCN-domain to a
node either in another PCN-domain or in a non PCN-domain. node either in another PCN-domain or in a non PCN-domain.
skipping to change at page 8, line 9 skipping to change at page 8, line 4
flow admission and termination for the PCN-domain, including the flow admission and termination for the PCN-domain, including the
PCN-egress-nodes which measure these PCN-marks. PCN-egress-nodes which measure these PCN-marks.
o PCN-boundary-node: a PCN-node that connects one PCN-domain to a o PCN-boundary-node: a PCN-node that connects one PCN-domain to a
node either in another PCN-domain or in a non PCN-domain. node either in another PCN-domain or in a non PCN-domain.
o PCN-interior-node: a node in a PCN-domain that is not a PCN- o PCN-interior-node: a node in a PCN-domain that is not a PCN-
boundary-node. boundary-node.
o PCN-node: a PCN-boundary-node or a PCN-interior-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 o PCN-egress-node: a PCN-boundary-node in its role in handling
traffic as it leaves a PCN-domain. traffic as it leaves a PCN-domain.
o PCN-ingress-node: a PCN-boundary-node in its role in handling o PCN-ingress-node: a PCN-boundary-node in its role in handling
traffic as it enters a PCN-domain. traffic as it enters a PCN-domain.
o PCN-traffic: A PCN-domain carries traffic of different DiffServ o PCN-traffic: A PCN-domain carries traffic of different DiffServ
classes [RFC4594]. Those using the PCN mechanisms are called PCN- behaviour aggregates [RFC2475]. Those using the PCN mechanisms
classes (collectively called PCN-traffic) and the corresponding are called PCN-BAs (collectively called PCN-traffic) and the
packets are PCN-packets. The same network may carry traffic using corresponding packets are PCN-packets. The same network may carry
other DiffServ classes. traffic using other DiffServ BAs. A PCN-flow is the unit of PCN-
traffic that the PCN-boundary-node admits (or terminates); the
unit could be a single microflow (as defined in [RFC2475]) or some
identifiable collection of microflows.
o Ingress-egress-aggregate: The collection of PCN-packets from all o Ingress-egress-aggregate: The collection of PCN-packets from all
PCN-flows that travel in one direction between a specific pair of PCN-flows that travel in one direction between a specific pair of
PCN-boundary-nodes. PCN-boundary-nodes.
o PCN-lower-rate: a reference rate configured for each link in the o PCN-lower-rate: a reference rate configured for each link in the
PCN-domain, which is lower than the PCN-upper-rate. It is used by PCN-domain, which is lower than the PCN-upper-rate. It is used by
a marking behaviour that determines whether a packet should be a marking behaviour that determines whether a packet should be
PCN-marked with a first encoding. PCN-marked with a first encoding.
skipping to change at page 9, line 8 skipping to change at page 9, line 4
of PCN-traffic that is PCN-marked is equal to the amount that of PCN-traffic that is PCN-marked is equal to the amount that
exceeds a particular rate (either the PCN-lower-rate or PCN-upper- exceeds a particular rate (either the PCN-lower-rate or PCN-upper-
rate). NOTE: The definition reflects the overall intent rather rate). NOTE: The definition reflects the overall intent rather
than its instantaneous behaviour, since the rate measured at a than its instantaneous behaviour, since the rate measured at a
particular moment depends on the behaviour, its implementation and particular moment depends on the behaviour, its implementation and
the traffic's variance as well as its rate. the traffic's variance as well as its rate.
o Pre-congestion: a condition of a link within a PCN-domain in which o Pre-congestion: a condition of a link within a PCN-domain in which
the PCN-node performs PCN-marking, in order to provide an "early the PCN-node performs PCN-marking, in order to provide an "early
warning" of potential congestion before there is any significant warning" of potential congestion before there is any significant
build-up of PCN-packets in the real queue. 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 process of setting the header in a PCN-packet o PCN-marking: the process of setting the header in a PCN-packet
based on defined rules, in reaction to pre-congestion. based on defined rules, in reaction to pre-congestion.
o PCN-feedback-information: information signalled by a PCN-egress- o PCN-feedback-information: information signalled by a PCN-egress-
node to a PCN-ingress-node or central control node, which is node to a PCN-ingress-node or central control node, which is
needed for the flow admission and flow termination mechanisms. needed for the flow admission and flow termination mechanisms.
3. Assumptions and constraints on scope 3. Assumptions and constraints on scope
The PCN WG's charter restricts the initial scope by a set of The scope of PCN is, at least initially (see Appendix A), restricted
assumptions. Here we list those assumptions and explain them. by the following assumptions:
1. these components are deployed in a single DiffServ domain, within 1. these components are deployed in a single DiffServ domain, within
which all PCN-nodes are PCN-enabled and trust each other for which all PCN-nodes are PCN-enabled and trust each other for
truthful PCN-marking and transport truthful PCN-marking and transport
2. all flows handled by these mechanisms are inelastic and 2. all flows handled by these mechanisms are inelastic and
constrained to a known peak rate through policing or shaping constrained to a known peak rate through policing or shaping
3. the number of PCN-flows across any potential bottleneck link is 3. the number of PCN-flows across any potential bottleneck link is
sufficiently large that stateless, statistical mechanisms can be sufficiently large that stateless, statistical mechanisms can be
effective. To put it another way, the aggregate bit rate of PCN- effective. To put it another way, the aggregate bit rate of PCN-
traffic across any potential bottleneck link needs to be traffic across any potential bottleneck link needs to be
sufficiently large relative to the maximum additional bit rate sufficiently large relative to the maximum additional bit rate
added by one flow added by one flow. This is the basic assumption of measurement-
based admission control.
4. PCN-flows may have different precedence, but the applicability of 4. PCN-flows may have different precedence, but the applicability of
the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.)
is out of scope is out of scope.
After completion of the initial phase, the PCN WG may re-charter to
develop solutions for specific scenarios where some of these
restrictions are not in place. It may also re-charter to consider
applying the PCN mechanisms to additional deployment scenarios. One
possible example is where a single PCN-domain encompasses several
DiffServ domains that don't trust each other (perhaps by using a
mechanism like re-ECN, [I-D.briscoe-re-pcn-border-cheat]. The WG may
also re-charter to investigate additional response mechanisms that
act on (pre-)congestion information. One example could be flow-rate
adaptation by elastic applications (rather than flow admission or
termination). The details of these work items are outside the scope
of the initial phase, but the WG may consider their requirements in
order to design components that are sufficiently general to support
such extensions in the future. The working assumption is that the
standards developed in the initial phase should not need to be
modified to satisfy the solutions for when these restrictions are
removed.
3.1. Assumption 1: Trust - controlled environment 3.1. Assumption 1: Trust and support of PCN - controlled environment
We assume that the PCN-domain is a controlled environment, i.e. all We assume that the PCN-domain is a controlled environment, i.e. all
the nodes in a PCN-domain run PCN and trust each other. There are the nodes in a PCN-domain run PCN and trust each other. There are
several reasons for proposing this assumption: several reasons for proposing this assumption:
o The PCN-domain has to be encircled by a ring of PCN-boundary- o The PCN-domain has to be encircled by a ring of PCN-boundary-
nodes, otherwise PCN-packets could enter the PCN-domain without nodes, otherwise traffic could enter a PCN BA without being
being subject to admission control, which would potentially subject to admission control, which would potentially degrade the
destroy the QoS of existing flows. QoS of existing PCN-flows.
o Similarly, a PCN-boundary-node has to trust that all the PCN-nodes o Similarly, a PCN-boundary-node has to trust that all the PCN-nodes
are doing PCN-marking. A non PCN-node wouldn't be able to alert mark PCN-traffic consistently. A node not doing PCN-marking
that it is suffering pre-congestion, which potentially would lead wouldn't be able to alert when it suffered pre-congestion, which
to too many PCN-flows being admitted (or too few being potentially would lead to too many PCN-flows being admitted (or
terminated). Worse, a rogue node could perform various attacks, too few being terminated). Worse, a rogue node could perform
as discussed in the Security Considerations section. various attacks, as discussed in the Security Considerations
section.
One way of assuring the above two points is that the entire PCN- One way of assuring the above two points is that the entire PCN-
domain is run by a single operator. Another possibility is that domain is run by a single operator. Another possibility is that
there are several operators but they trust each other to a sufficient there are several operators but they trust each other to a sufficient
level, in their handling of PCN-traffic. level, in their handling of PCN-traffic.
Note: All PCN-nodes need to be trustworthy. However if it's known Note: All PCN-nodes need to be trustworthy. However if it's known
that an interface cannot become pre-congested then it's not strictly that an interface cannot become pre-congested then it's not strictly
necessary for it to be capable of PCN-marking. But this must be necessary for it to be capable of PCN-marking. But this must be
known even in unusual circumstances, eg after the failure of some known even in unusual circumstances, eg after the failure of some
skipping to change at page 10, line 48 skipping to change at page 10, line 30
3.2. Assumption 2: Real-time applications 3.2. Assumption 2: Real-time applications
We assume that any variation of source bit rate is independent of the We assume that any variation of source bit rate is independent of the
level of pre-congestion. We assume that PCN-packets come from real level of pre-congestion. We assume that PCN-packets come from real
time applications generating inelastic traffic [Shenker] like voice time applications generating inelastic traffic [Shenker] like voice
and video requiring low delay, jitter and packet loss, for example and video requiring low delay, jitter and packet loss, for example
the Controlled Load Service, [RFC2211], and the Telephony service the Controlled Load Service, [RFC2211], and the Telephony service
class, [RFC4594]. This assumption is to help focus the effort where class, [RFC4594]. This assumption is to help focus the effort where
it looks like PCN would be most useful, ie the sorts of applications it looks like PCN would be most useful, ie the sorts of applications
where per flow QoS is a known requirement. For instance, the impact where per flow QoS is a known requirement. In other words we focus
of this assumption would be to guide simulations work. on PCN providing a benefit to inelastic traffic (PCN may or may not
provide a benefit to other types of traffic). For instance, the
impact of this assumption would be to guide simulations work.
3.3. Assumption 3: Many flows and additional load 3.3. Assumption 3: Many flows and additional load
We assume that there are many flows on any bottleneck link in the We assume that there are many PCN-flows on any bottleneck link in the
PCN-domain (or, to put it another way, the aggregate bit rate of PCN- PCN-domain (or, to put it another way, the aggregate bit rate of PCN-
traffic across any potential bottleneck link is sufficiently large traffic across any potential bottleneck link is sufficiently large
relative to the maximum additional bit rate added by one flow). relative to the maximum additional bit rate added by one PCN-flow).
Measurement-based admission control assumes that the present is a Measurement-based admission control assumes that the present is a
reasonable prediction of the future: the network conditions are reasonable prediction of the future: the network conditions are
measured at the time of a new flow request, however the actual measured at the time of a new flow request, however the actual
network performance must be OK during the call some time later. One network performance must be OK during the call some time later. One
issue is that if there are only a few variable rate flows, then the issue is that if there are only a few variable rate flows, then the
aggregate traffic level may vary a lot, perhaps enough to cause some aggregate traffic level may vary a lot, perhaps enough to cause some
packets to get dropped. If there are many flows then the aggregate packets to get dropped. If there are many flows then the aggregate
traffic level should be statistically smoothed. How many flows is traffic level should be statistically smoothed. How many flows is
enough depends on a number of things such as the variation in each enough depends on a number of things such as the variation in each
flow's rate, the total rate of PCN-traffic, and the size of the flow's rate, the total rate of PCN-traffic, and the size of the
skipping to change at page 11, line 49 skipping to change at page 11, line 31
marking is being applied to traffic scheduled with the expedited marking is being applied to traffic scheduled with the expedited
forwarding per-hop behaviour, [RFC3246], or traffic with similar forwarding per-hop behaviour, [RFC3246], or traffic with similar
characteristics. characteristics.
The following two assumptions apply if the PCN WG decides to encode The following two assumptions apply if the PCN WG decides to encode
PCN-marking in the ECN-field. PCN-marking in the ECN-field.
o It is assumed that PCN-nodes do not perform ECN, [RFC3168], on o It is assumed that PCN-nodes do not perform ECN, [RFC3168], on
PCN-packets. PCN-packets.
o If a packet that is part of a PCN-flow arrives at a PCN-ingress- o What to do if a packet that is part of a PCN-flow arrives at a
node with its CE (Congestion experienced) codepoint set, then we PCN-ingress-node with its CE (Congestion experienced) codepoint
assume that the PCN-ingress-node drops the packet. After its set (or if it detects that the ECN-nonce in use). There are
initial Charter is complete, the WG may decide to work on a several possibilities (not discussed further in this document)
mechanism (such as through a signalling extension) that enables about what the PCN-ingress-node should do:
ECN-marking to be carried transparently across the PCN-domain.
* drop the packet
* downgrade the packet to non PCN-BA, eg best effort
* tunnel the packet, so that the ECN-marking is carried
transparently across the PCN-domain.
4. High-level functional architecture 4. High-level functional architecture
The high-level approach is to split functionality between: The high-level approach is to split functionality between:
o PCN-interior-nodes 'inside' the PCN-domain, which monitor their o PCN-interior-nodes 'inside' the PCN-domain, which monitor their
own state of pre-congestion on each outgoing interface and mark own state of pre-congestion on each outgoing interface and mark
PCN-packets if appropriate. They are not flow-aware, nor aware of PCN-packets if appropriate. They are not flow-aware, nor aware of
ingress-egress-aggregates. The functionality is also done by PCN- ingress-egress-aggregates. The functionality is also done by PCN-
ingress-nodes for their outgoing interfaces (ie those 'inside' the ingress-nodes for their outgoing interfaces (ie those 'inside' the
PCN-domain). PCN-domain).
o PCN-boundary-nodes at the edge of the PCN-domain, which control o PCN-boundary-nodes at the edge of the PCN-domain, which control
admission of new PCN-flows and termination of existing PCN-flows, admission of new PCN-flows and termination of existing PCN-flows,
based on information from PCN-interior-nodes. This information is based on information from PCN-interior-nodes. This information is
in the form of the PCN-marked data packets (which are intercepted in the form of the PCN-marked data packets (which are intercepted
by the PCN-egress-nodes) and not signalling messages. Generally by the PCN-egress-nodes) and not signalling messages. Generally
PCN-ingress-nodes are flow-aware and in several deployment PCN-ingress-nodes are flow-aware.
scenarios PCN-egress-nodes will also be flow aware.
The aim of this split is to keep the bulk of the network simple, The aim of this split is to keep the bulk of the network simple,
scalable and robust, whilst confining policy, application-level and scalable and robust, whilst confining policy, application-level and
security interactions to the edge of the PCN-domain. For example the security interactions to the edge of the PCN-domain. For example the
lack of flow awareness means that the PCN-interior-nodes don't care lack of flow awareness means that the PCN-interior-nodes don't care
about the flow information associated with the PCN-packets that they about the flow information associated with the PCN-packets that they
carry, nor do the PCN-boundary-nodes care about which PCN-interior- carry, nor do the PCN-boundary-nodes care about which PCN-interior-
nodes its flows traverse. nodes its flows traverse.
The objective is to standardise PCN-marking behaviour, but
potentially produce more than one (informational) RFC describing how
PCN-boundary-nodes react to PCN-marks.
Note: Section 4 and Section 5 talk about PCN functionality being
configured on outgoing interfaces of PCN-nodes. Alternatively, PCN
functionality could be configured on the ingress interfaces of PCN-
nodes, however a consistent choice must be made across the PCN-domain
to ensure that the PCN mechanisms protect all links. This document
assumes configuration on the egress interfaces, because in DiffServ
networks today DiffServ functionality is usually implemented on
egress interfaces.
4.1. Flow admission 4.1. Flow admission
At a high level, flow admission control works as follows. In order At a high level, flow admission control works as follows. In order
to generate information about the current state of the PCN-domain, to generate information about the current state of the PCN-domain,
each PCN-node PCN-marks packets if it is "pre-congested". Exactly 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 how a PCN-node decides if it is "pre-congested" (the algorithm) and
exactly how packets are "PCN-marked" (the encoding) will be defined exactly how packets are "PCN-marked" (the encoding) will be defined
in a separate standards-track document, but at a high level it is in a separate standards-track document, but at a high level it is
expected to be as follows: expected to be as follows:
skipping to change at page 13, line 16 skipping to change at page 13, line 16
encoding) by setting fields in the header to specific values. It encoding) by setting fields in the header to specific values. It
is expected that the ECN and/or DSCP fields will be used. is expected that the ECN and/or DSCP fields will be used.
NOTE: Two main categories of algorithm have been proposed: if the NOTE: Two main categories of algorithm have been proposed: if the
algorithm uses threshold-marking then all PCN-packets are marked if algorithm uses threshold-marking then all PCN-packets are marked if
the current rate exceeds the PCN-lower-rate, whereas if the algorithm the current rate exceeds the PCN-lower-rate, whereas if the algorithm
uses excess-rate-marking the amount marked is equal to the amount in uses excess-rate-marking the amount marked is equal to the amount in
excess of the PCN-lower-rate. However, note that this description excess of the PCN-lower-rate. However, note that this description
reflects the overall intent of the algorithm rather than its reflects the overall intent of the algorithm rather than its
instantaneous behaviour, since the rate measured at a particular instantaneous behaviour, since the rate measured at a particular
moment depends on the detailed algorithm, its implementation (eg moment depends on the detailed algorithm, its implementation and the
virtual queue, token bucket...) and the traffic's variance as well as traffic's variance as well as its rate (eg marking may well continue
its rate (eg marking may well continue after a recent overload even after a recent overload even after the instantaneous rate has
after the instantaneous rate has dropped). dropped).
The PCN-boundary-nodes monitor the PCN-marked packets in order to The PCN-boundary-nodes monitor the PCN-marked packets in order to
extract information about the current state of the PCN-domain. Based extract information about the current state of the PCN-domain. Based
on this monitoring, a decision is made about whether to admit a on this monitoring, a decision is made about whether to admit a
prospective new flow. Exactly how the admission control decision is prospective new flow. Exactly how the admission control decision is
made will be defined separately (at the moment the intention is that made will be defined separately (at the moment the intention is that
there will be one or more informational-track RFCs), but at a high there will be one or more informational-track RFCs), but at a high
level two approaches have been proposed to date: level two approaches have been proposed to date:
o the PCN-egress-node measures (possibly as a moving average) the o the PCN-egress-node measures (possibly as a moving average) the
fraction of the PCN-traffic that is PCN-marked. The fraction is fraction of the PCN-traffic that is PCN-marked. The fraction is
measured for a specific ingress-egress-aggregate. If the fraction measured for a specific ingress-egress-aggregate. If the fraction
is below a threshold value then the new flow is admitted. is below a threshold value then the new flow is admitted.
o if the PCN-egress-node receives one (or several) PCN-marked o if the PCN-egress-node receives one (or several) PCN-marked
packets, then a new flow is blocked. packets, then a new flow is blocked, otherwise it is admitted.
Note that the PCN-lower-rate is a parameter that can be configured by Note that the PCN-lower-rate is a parameter that can be configured by
the operator. It will be set lower than the traffic rate at which the operator. It will be set lower than the traffic rate at which
the link becomes congested and the node drops packets. (Hence, by the link becomes congested and the node drops packets.
analogy with ECN we call our mechanism Pre-Congestion Notification.)
Note also that the admission control decision is made for a Note also that the admission control decision is made for a
particular ingress-egress-aggregate. So it is quite possible for a particular pair of PCN-boundary-nodes. So it is quite possible for a
new flow to be admitted between one pair of PCN-boundary-nodes, new flow to be admitted between one pair of PCN-boundary-nodes,
whilst at the same time another admission request is blocked between whilst at the same time another admission request is blocked between
a different pair of PCN-boundary-nodes. a different pair of PCN-boundary-nodes.
4.2. Flow termination 4.2. Flow termination
At a high level, flow termination control works as follows. Each At a high level, flow termination control works as follows. Each
PCN-node PCN-marks packets in a similar fashion to above. An obvious PCN-node PCN-marks packets in a similar fashion to above, with all
approach is for the algorithm to use a second configured parameter, proposals using an excess-rate-marking approach (Section 4.1). An
PCN-upper-rate, and a second header encoding. However there is also obvious approach is for the algorithm to use a second configured
a proposal to use the same rate and the same encoding. Several parameter, PCN-upper-rate, and a second header encoding. However
approaches have been proposed to date about how to convert this there is also a proposal to use the same rate and the same encoding.
information into a flow termination decision; at a high level these Several approaches have been proposed to date about how to convert
are as follows: this information into a flow termination decision; at a high level
these are as follows:
o One approach measures the rate of unmarked PCN-traffic (ie not o In one approach the PCN-egress-node measures the rate of unmarked
PCN-upper-rate-marked) at the PCN-egress-node, which is the amount PCN-traffic (ie not PCN-upper-rate-marked), which is the amount of
of PCN-traffic that can actually be supported; the PCN-ingress- PCN-traffic that can actually be supported. Also the PCN-ingress-
node measures the rate of PCN-traffic that is destined for this node measures the rate of PCN-traffic that is destined for this
specific PCN-egress-node, and hence can calculate the excess specific PCN-egress-node, and hence can calculate the excess
amount that should be terminated. amount that should be terminated.
o Another approach instead measures the rate of PCN-upper-rate- o Another approach instead measures the rate of PCN-upper-rate-
marked traffic and calculates and selects the flows that should be marked traffic and calculates and selects the flows that should be
terminated. terminated.
o Another approach terminates any PCN-flow with a PCN-upper-rate- o Another approach terminates any PCN-flow with a PCN-upper-rate-
marked packet. Compared with the approaches above, PCN-marking marked packet. Compared with the approaches above, PCN-marking
needs to be done at a reduced rate otherwise far too much traffic needs to be done at a reduced rate (every "s" bytes of excess
would be terminated. traffic) otherwise far too much traffic would be terminated.
o Another approach uses only one sort of marking, which is based on o Another approach uses only one sort of marking, which is based on
the PCN-lower-rate, to decide not only whether to admit more PCN- the PCN-lower-rate, to decide not only whether to admit more PCN-
flows but also whether any PCN-flows need to be terminated. It flows but also whether any PCN-flows need to be terminated. It
assumes that the ratio of the (implicit) PCN-upper-rate and the assumes that the ratio of the (implicit) PCN-upper-rate and the
PCN-lower-rate is the same on all links. This approach measures PCN-lower-rate is the same on all links. This approach measures
the rate of unmarked PCN-traffic at a PCN-egress-node. The PCN- the rate of unmarked PCN-traffic at a PCN-egress-node. The PCN-
ingress-node uses this measurement to compute the implicit PCN- ingress-node uses this measurement to compute the implicit PCN-
upper-rate of the bottleneck link. It then measures the rate of upper-rate of the bottleneck link. It then measures the rate of
PCN-traffic that is destined for this specific PCN-egress-node and PCN-traffic that is destined for this specific PCN-egress-node and
hence can calculate the amount that should be terminated. hence can calculate the amount that should be terminated.
Since flow termination is designed for "abnormal" circumstances, it Since flow termination is designed for "abnormal" circumstances, it
is quite likely that some PCN-nodes are congested and hence packets is quite likely that some PCN-nodes are congested and hence packets
are being dropped and/or significantly queued. The flow termination are being dropped and/or significantly queued. The flow termination
mechanism must bear this in mind. mechanism must bear this in mind.
Note also that the termination control decision is made for a Note also that the termination control decision is made for a
particular ingress-egress-aggregate. So it is quite possible for particular pair of PCN-boundary-nodes. So it is quite possible for
PCN-flows to be terminated between one pair of PCN-boundary-nodes, PCN-flows to be terminated between one pair of PCN-boundary-nodes,
whilst at the same time none are terminated between a different pair whilst at the same time none are terminated between a different pair
of PCN-boundary-nodes. of PCN-boundary-nodes.
4.3. Flow admission and flow termination 4.3. Flow admission and flow termination
Although designed to work together, flow admission and flow Although designed to work together, flow admission and flow
termination are independent mechanisms, and the use of one does not termination are independent mechanisms, and the use of one does not
require or prevent the use of the other. require or prevent the use of the other.
skipping to change at page 15, line 33 skipping to change at page 15, line 33
A different possibility is to configure only the PCN-lower-rate and A different possibility is to configure only the PCN-lower-rate and
hence only do one type of PCN-marking, but generate admission and hence only do one type of PCN-marking, but generate admission and
flow termination responses from different levels of marking. This is flow termination responses from different levels of marking. This is
suggested in [I-D.charny-pcn-single-marking] which gives some of the suggested in [I-D.charny-pcn-single-marking] which gives some of the
pros and cons of this approach. pros and cons of this approach.
4.4. Information transport 4.4. Information transport
The transport of pre-congestion information from a PCN-node to a PCN- The transport of pre-congestion information from a PCN-node to a PCN-
egress-node is through PCN-markings in data packet headers, no egress-node is through PCN-markings in data packet headers, ie "in-
signalling protocol messaging is needed. However, signalling is band": no signalling protocol messaging is needed. However,
needed to transport PCN-feedback-information between the PCN- signalling is needed to transport PCN-feedback-information between
boundary-nodes, for example to convey the fraction of PCN-marked the PCN-boundary-nodes, for example to convey the fraction of PCN-
traffic from a PCN-egress-node to the relevant PCN-ingress-node. marked traffic from a PCN-egress-node to the relevant PCN-ingress-
Exactly what information needs to be transported will be described in node. Exactly what information needs to be transported will be
the future PCN WG document(s) about the boundary mechanisms. The described in the future PCN WG document(s) about the boundary
signalling could be done by an extension of RSVP or NSIS, for mechanisms. The signalling could be done by an extension of RSVP or
instance; protocol work will be done by the relevant WG, but for NSIS, for instance; protocol work will be done by the relevant WG,
example [I-D.lefaucheur-rsvp-ecn] describes the extensions needed for but for example [I-D.lefaucheur-rsvp-ecn] describes the extensions
RSVP. needed for RSVP.
4.5. PCN-traffic 4.5. PCN-traffic
The following are some high-level points about how PCN works: The following are some high-level points about how PCN works:
o There needs to be a way for a PCN-node to distinguish PCN-traffic o There needs to be a way for a PCN-node to distinguish PCN-traffic
from non PCN-traffic. They may be distinguished using the DSCP from non PCN-traffic. They may be distinguished using the DSCP
field and/or ECN field. field and/or ECN field.
o The PCN mechanisms may be applied to more than one traffic class o The PCN mechanisms may be applied to more than one behaviour
(which are distinguished by DSCP). aggregate (which are distinguished by DSCP).
o There may be traffic that is more important than PCN, perhaps a o There may be traffic that is more important than PCN, perhaps a
particular application or an operator's control messages. A PCN- particular application or an operator's control messages. A PCN-
node may dedicate capacity to such traffic or priority schedule it node may dedicate capacity to such traffic or priority schedule it
over PCN. In the latter case its traffic needs to contribute to over PCN. In the latter case its traffic needs to contribute to
the PCN meters. the PCN meters.
o There will be traffic less important than PCN. For instance best o There will be traffic less important than PCN. For instance best
effort or assured forwarding traffic. It will be scheduled at effort or assured forwarding traffic. It will be scheduled at
lower priority than PCN, and use a separate queue or queues. lower priority than PCN, and use a separate queue or queues.
skipping to change at page 17, line 16 skipping to change at page 17, line 16
The section then discusses some other detailed topics: The section then discusses some other detailed topics:
1. addressing 1. addressing
2. tunnelling 2. tunnelling
3. fault handling 3. fault handling
5.1. PCN-interior-node functions 5.1. PCN-interior-node functions
Each interface of the PCN-domain is upgraded with the following Each interface of the PCN-domain is configured with the following
functionality: functionality:
o Packet classify - decide whether an incoming packet is a PCN- o Packet classify - decide whether an incoming packet is a PCN-
packet or not. Another PCN WG document will specify encoding, packet or not. Another PCN WG document will specify encoding,
using the DSCP and/or ECN fields. using the DSCP and/or ECN fields.
o PCN-meter - measure the 'amount of PCN-traffic'. The measurement o PCN-meter - measure the 'amount of PCN-traffic'. The measurement
is made as an aggregate of all PCN-packets, and not per flow. is made as an aggregate of all PCN-packets, and not per flow.
o PCN-mark - algorithms determine whether to PCN-mark PCN-packets o PCN-mark - algorithms determine whether to PCN-mark PCN-packets
skipping to change at page 17, line 43 skipping to change at page 17, line 43
These functions are needed for each interface of the PCN-domain. These functions are needed for each interface of the PCN-domain.
They are therefore needed on all interfaces of PCN-interior-nodes, They are therefore needed on all interfaces of PCN-interior-nodes,
and on the interfaces of PCN-boundary-nodes that are internal to the and on the interfaces of PCN-boundary-nodes that are internal to the
PCN-domain. There may be more than one PCN-meter and marker PCN-domain. There may be more than one PCN-meter and marker
installed at a given interface, eg one for admission and one for installed at a given interface, eg one for admission and one for
termination. termination.
5.2. PCN-ingress-node functions 5.2. PCN-ingress-node functions
Each ingress interface of the PCN-domain is upgraded with the Each ingress interface of the PCN-domain is configured with the
following functionality: following functionality:
o Packet classify - decide whether an incoming packet is part of a o Packet classify - decide whether an incoming packet is part of a
previously admitted microflow, by using a filter spec (eg DSCP, previously admitted microflow, by using a filter spec (eg DSCP,
source and destination addresses and port numbers) source and destination addresses and port numbers)
o Police - police, by dropping or re-marking with a non-PCN DSCP, o Police - police, by dropping or re-marking with a non-PCN DSCP,
any packets received with a DSCP demanding PCN transport that do any packets received with a DSCP demanding PCN transport that do
not belong to an admitted flow. Similarly, police packets that not belong to an admitted flow. Similarly, police packets that
are part of a previously admitted microflow, to check that the are part of a previously admitted microflow, to check that the
microflow keeps to the agreed rate or flowspec (eg RFC1633 microflow keeps to the agreed rate or flowspec (eg RFC1633
[RFC1633] and NSIS equivalent). [RFC1633] and NSIS equivalent). There is a need to be careful to
avoid re-ordering traffic.
o PCN-colour - set the DSCP field or DSCP and ECN fields to the o PCN-colour - set the DSCP field or DSCP and ECN fields to the
appropriate value(s) for a PCN-packet. The draft about PCN- appropriate value(s) for a PCN-packet. The draft about PCN-
encoding will discuss further. encoding will discuss further.
o PCN-meter - make "measurements of PCN-traffic". Some approaches o PCN-meter - make "measurements of PCN-traffic". Some approaches
to flow termination require the PCN-ingress-node to measure the to flow termination require the PCN-ingress-node to measure the
(aggregate) rate of PCN-traffic towards a particular PCN-egress- (aggregate) rate of PCN-traffic towards a particular PCN-egress-
node. node.
The first two are policing functions, needed to make sure that PCN- The first two are policing functions, needed to make sure that PCN-
packets let into the PCN-domain belong to a flow that's been admitted packets admitted into the PCN-domain belong to a flow that's been
and to ensure that the flow doesn't go at a faster rate than agreed. admitted and to ensure that the flow keeps to the flowspec agreed (eg
The filter spec will for example come from the flow request message doesn't go at a faster rate and is inelastic traffic). Installing
(outside scope of PCN WG, see [I-D.briscoe-tsvwg-cl-architecture] for the filter spec will typically be done by the signalling protocol, as
an example using RSVP). PCN-colouring allows the rest of the PCN- will re-installing the filter, for example after a re-route that
domain to recognise PCN-packets. changes the PCN-ingress-node (see [I-D.briscoe-tsvwg-cl-architecture]
for an example using RSVP). PCN-colouring allows the rest of the
PCN-domain to recognise PCN-packets.
5.3. PCN-egress-node functions 5.3. PCN-egress-node functions
Each egress interface of the PCN-domain is upgraded with the Each egress interface of the PCN-domain is configured with the
following functionality: following functionality:
o Packet classify - determine which PCN-ingress-node a PCN-packet o Packet classify - determine which PCN-ingress-node a PCN-packet
has come from. has come from.
o PCN-meter - make measurements of PCN-traffic. The measurement(s) o PCN-meter - "measure PCN-traffic" or "monitor PCN-marks".
is made as an aggregate (ie not per flow) of all PCN-packets from
a particular PCN-ingress-node.
o PCN-colour - for PCN-packets, set the DSCP and ECN fields to the o PCN-colour - for PCN-packets, set the DSCP and ECN fields to the
appropriate values for use outside the PCN-domain. appropriate values for use outside the PCN-domain.
Another PCN WG document, about boundary mechanisms, will describe Another PCN WG document, about boundary mechanisms, will describe
what the "measurements of PCN-traffic" are. This depends on whether PCN-metering in more detail. As described in Section 4.1 and Section
the measurement is targeted at admission control or flow termination. 4.2, at present there are two alternative proposals: to measure as an
It also depends on what encoding and PCN-marking algorithms are aggregate (ie not per flow) all PCN-packets from a particular PCN-
specified by the PCN WG. ingress-node; or to monitor 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 at admission
control or flow termination. It also depends on what encoding and
PCN-marking algorithms are specified by the PCN WG.
5.4. Admission control functions 5.4. Other admission control functions
Specific admission control functions can be performed at a PCN- As well as the functions covered above (Sections 5.1, 5.2, 5.3),
other specific admission control functions can be performed at a PCN-
boundary-node (PCN-ingress-node or PCN-egress-node) or at a boundary-node (PCN-ingress-node or PCN-egress-node) or at a
centralised node, but not at normal PCN-interior-nodes. The centralised node, but not at normal PCN-interior-nodes. The
functions are: functions are:
o Make decision about admission - compare the required "measurements o Make decision about admission - based on the output of the PCN-
of PCN-traffic" (output of the PCN-egress-node's PCN-meter egress-node's PCN-meter function. In the case where it "measures
function) with some reference level, and hence decide whether to PCN-traffic", the measured traffic on the ingress-egress-aggregate
admit the potential new PCN-flow. As well as the PCN is compared with some reference level. In the case where it
measurements, the decision takes account of policy and application "monitors PCN-marks", then the decision is based on whether one
layer requirements. (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 to the o Communicate decision about admission - signal the decision to the
node making the admission control request (which may be outside node making the admission control request (which may be outside
the PCN-domain), and to the policer (PCN-ingress-node function) the PCN-domain), and to the policer (PCN-ingress-node function)
for enforcement of the decision.
There are various possibilities for how the functionality can be There are various possibilities for how the functionality can be
distributed (we assume the operator would configure which is used): distributed (we assume the operator would configure which is used):
o The decision is made at the PCN-egress-node and signalled to the o The decision is made at the PCN-egress-node and signalled to the
PCN-ingress-node PCN-ingress-node
o The decision is made at the PCN-ingress-node, which requires that o The decision is made at the PCN-ingress-node, which requires that
the PCN-egress-node signals to the PCN-ingress-node the fraction the PCN-egress-node signals PCN-feedback-information to the PCN-
of PCN-traffic that is PCN-marked (or whatever the PCN WG agrees ingress-node. For example, in the case where the PCN-meter
as the required "measurements of PCN-traffic"). function is to "measure PCN-traffic" it could signal the fraction
of PCN-traffic that is PCN-marked.
o The decision is made at a centralised node, which requires that o The decision is made at a centralised node (see Appendix).
the PCN-egress-node signals its measurements to the centralised
node, and that the centralised node signals to the PCN-ingress-
node about the decision about admission control. It would be
possible for the centralised node to be one of the PCN-boundary-
nodes, when clearly the signalling would sometimes be replaced by
a message internal to the node.
5.5. Flow termination functions The decision needs to be passed to the application layer so that it
can take the appropriate action.
5.5. Other flow termination functions
Specific termination control functions can be performed at a PCN- Specific termination control functions can be performed at a PCN-
boundary-node (PCN-ingress-node or PCN-egress-node) or at a boundary-node (PCN-ingress-node or PCN-egress-node) or at a
centralised node, but not at normal PCN-interior-nodes. There are centralised node, but not at normal PCN-interior-nodes. There are
various possibilities for how the functionality can be distributed, various possibilities for how the functionality can be distributed,
similar to those discussed above in the Admission control section; similar to those discussed above in the Admission control section;
the flow termination decision could be made at the PCN-ingress-node, the flow termination decision could be made at the PCN-ingress-node,
the PCN-egress-node or at some centralised node. The functions are: the PCN-egress-node or at some centralised node. The functions are:
o PCN-meter at PCN-egress-node - make "measurements of PCN-traffic" o PCN-meter at PCN-egress-node - similarly to flow admission, there
from a particular PCN-ingress-node. are two 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 o (if required) PCN-meter at PCN-ingress-node - make "measurements
of PCN-traffic" being sent towards a particular PCN-egress-node; of PCN-traffic" being sent towards a particular PCN-egress-node;
again, this is done for the ingress-egress-aggregate and not per again, this is done for the ingress-egress-aggregate and not per
flow. flow.
o (if required) Communicate "measurements of PCN-traffic" to the o (if required) Communicate PCN-feedback-information to the node
node that makes the flow termination decision. For example, if that makes the flow termination decision. For example, as in
the PCN-ingress-node makes the decision then communicate the PCN- [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress-
egress-node's measurements to it (as in node's measurements to the PCN-ingress-node.
[I-D.briscoe-tsvwg-cl-architecture]).
o Make decision about flow termination - use the "measurements of o Make decision about flow termination - use the information from
PCN-traffic" to decide which PCN-flow or PCN-flows to terminate. the PCN-meter(s) to decide which PCN-flow or PCN-flows to
The decision takes account of policy and application layer terminate. The decision takes account of policy and application
requirements. layer requirements.
o Communicate decision about flow termination - signal the decision o Communicate decision about flow termination - signal the decision
to the node that is able to terminate the flow (which may be to the node that is able to terminate the flow (which may be
outside the PCN-domain), and to the policer (PCN-ingress-node outside the PCN-domain), and to the policer (PCN-ingress-node
function). function) for enforcement of the decision.
5.6. Addressing 5.6. Addressing
PCN-nodes may need to know the address of other PCN-nodes: PCN-nodes may need to know the address of other PCN-nodes. Note: in
all cases PCN-interior-nodes don't need to know the address of any
other PCN-nodes (except as normal their next hop neighbours, for
routing purposes).
o Note: in all cases PCN-interior-nodes don't need to know the The PCN-egress-node needs to know the address of the PCN-ingress-node
address of any other PCN-nodes (except as normal their next hop associated with a flow, at a minimum so that the PCN-ingress-node can
neighbours, for routing purposes) be informed to enforce the admission decision (and any flow
termination decision) through policing. There are various
possibilities for how the PCN-egress-node can do this, ie associate
the received packet to the correct ingress-egress-aggregate. It is
not the intention of this document to mandate a particular mechanism.
o in the cases of admission or termination decision by a PCN- o The addressing information can be gathered from signalling. For
boundary-node, the PCN-egress-node needs to know the address of example, regular processing of an RSVP Path message, as the PCN-
the PCN-ingress-node associated with a flow, at a minimum so that ingress-node is the previous RSVP hop (PHOP)
the PCN-ingress-node can be informed to enforce the admission ([I-D.lefaucheur-rsvp-ecn]).
decision (and any flow termination decision) through policing.
The addressing information can be gathered from signalling, for
example as described for RSVP in [I-D.lefaucheur-rsvp-ecn].
Another alternative is to use a probe packet that includes as
payload the address of the PCN-ingress-node. Alternatively, if
PCN-traffic is always tunnelled across the PCN-domain, then the
PCN-ingress-node's address is simply the source address of the
outer packet header; then the PCN-ingress-node needs to learn the
address of the PCN-egress-node, either by manual configuration or
by one of the automated tunnel endpoint discovery mechanisms (such
as signalling or probing over the data route, interrogating
routing or using a centralised broker).
o in the cases of admission or termination decision by a central o Use a probe packet that includes as payload the address of the
control node, the PCN-egress-node needs to be configured with the PCN-ingress-node.
address of the centralised node. In addition, depending on the
exact deployment scenario and its signalling, the centralised node o Always tunnel PCN-traffic across the PCN-domain. Then the PCN-
may need to know the addresses of the PCN-ingress-node and PCN- ingress-node's address is simply the source address of the outer
egress-node, the PCN-egress-node may need to know the address of packet header. The PCN-ingress-node needs to learn the address of
the PCN-ingress-node, and the PCN-ingress-node may need to know the PCN-egress-node, either by manual configuration or by one of
the address of the centralised node and the PCN-egress-node. the automated tunnel endpoint discovery mechanisms (such as
NOTE: Consideration of the centralised case is out of scope of the signalling or probing over the data route, interrogating routing
initial PCN WG Charter. or using a centralised broker).
5.7. Tunnelling 5.7. Tunnelling
Tunnels may originate and/or terminate within a PCN-domain. It is Tunnels may originate and/or terminate within a PCN-domain. It is
important that the PCN-marking of any packet can potentially important that the PCN-marking of any packet can potentially
influence PCN's flow admission control and termination - it shouldn't influence PCN's flow admission control and termination - it shouldn't
matter whether the packet happens to be tunnelled at the PCN-node matter whether the packet happens to be tunnelled at the PCN-node
that PCN-marks the packet, or indeed whether it's decapsulated or that PCN-marks the packet, or indeed whether it's decapsulated or
encapsulated by a subsequent PCN-node. This suggests that the encapsulated by a subsequent PCN-node. This suggests that the
"uniform conceptual model" described in [RFC2983] should be re- "uniform conceptual model" described in [RFC2983] should be re-
skipping to change at page 21, line 32 skipping to change at page 21, line 35
o any PCN-marking is copied into the outer header o any PCN-marking is copied into the outer header
Similarly, in line with the "uniform conceptual model" of [RFC2983] Similarly, in line with the "uniform conceptual model" of [RFC2983]
and the "full-functionality option" of [RFC3168], the following rule and the "full-functionality option" of [RFC3168], the following rule
is applied if decapsulation is done within the PCN-domain: is applied if decapsulation is done within the PCN-domain:
o if the outer header's marking state is more severe then it is o if the outer header's marking state is more severe then it is
copied onto the inner header copied onto the inner header
o NB the order of increasing severity is: unmarked; PCN-marking with o Note: the order of increasing severity is: unmarked; PCN-marking
first encoding (ie associated with the PCN-lower-rate); PCN- with first encoding (ie associated with the PCN-lower-rate); PCN-
marking with second encoding (ie associated with the PCN-upper- marking with second encoding (ie associated with the PCN-upper-
rate) rate)
An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to
PCN-egress-nodes. The PCN-marks shouldn't be visible outside the PCN-egress-nodes. The PCN-marks shouldn't be visible outside the
PCN-domain, which can be achieved by doing the PCN-colour function PCN-domain, which can be achieved by doing the PCN-colour function
(Section 5.3) after all the other (PCN and tunnelling) functions. (Section 5.3) after all the other (PCN and tunnelling) functions.
The potential reasons for doing such tunnelling are: the PCN-egress- The potential reasons for doing such tunnelling are: the PCN-egress-
node then automatically knows the address of the relevant PCN- node then automatically knows the address of the relevant PCN-
ingress-node for a flow; even if ECMP is running, all PCN-packets on ingress-node for a flow; even if ECMP is running, all PCN-packets on
a particular ingress-egress-aggregate follow the same path. But it a particular ingress-egress-aggregate follow the same path. But it
also has drawbacks, for example the additional overhead in terms of also has drawbacks, for example the additional overhead in terms of
bandwidth and processing. bandwidth and processing, and the cost of setting up a mesh of
tunnels between PCN-boundary-nodes (there is an N^2 scaling issue).
Potential issues arise for a "partially PCN-capable tunnel", ie where Potential issues arise for a "partially PCN-capable tunnel", ie where
only one tunnel endpoint is in the PCN domain: only one tunnel endpoint is in the PCN domain:
1. The tunnel starts outside a PCN-domain and finishes inside it. 1. The tunnel starts outside a PCN-domain and finishes inside it.
If the packet arrives at the tunnel ingress with the same If the packet arrives at the tunnel ingress with the same
encoding as used within the PCN-domain to indicate PCN-marking, encoding as used within the PCN-domain to indicate PCN-marking,
then this could lead the PCN-egress-node to falsely measure pre- then this could lead the PCN-egress-node to falsely measure pre-
congestion. congestion.
2. The tunnel starts inside a PCN-domain and finishes outside it. 2. The tunnel starts inside a PCN-domain and finishes outside it.
If the packet arrives at the tunnel ingress already PCN-marked, If the packet arrives at the tunnel ingress already PCN-marked,
then it will still have the same encoding when it's decapsulated then it will still have the same encoding when it's decapsulated
which could potentially confuse nodes beyond the tunnel egress. which could potentially confuse nodes beyond the tunnel egress.
In line with the solution for partially capable DiffServ tunnels in In line with the solution for partially capable DiffServ tunnels in
[2983], the following rules are applied: [RFC2983], the following rules are applied:
o For case (1), the tunnel egress node clears any PCN-marking on the o For case (1), the tunnel egress node clears any PCN-marking on the
inner header. This rule is applied before the 'copy on inner header. This rule is applied before the 'copy on
decapsulation' rule above. decapsulation' rule above.
o For case (2), the tunnel ingress node clears any PCN-marking on o For case (2), the tunnel ingress node clears any PCN-marking on
the inner header. This rule is applied after the 'copy on the inner header. This rule is applied after the 'copy on
encapsulation' rule above. encapsulation' rule above.
Note that the above implies that one has to know, or figure out, the Note that the above implies that one has to know, or figure out, the
skipping to change at page 22, line 46 skipping to change at page 22, line 47
admitted traffic, flows will gracefully continue. If instead this admitted traffic, flows will gracefully continue. If instead this
causes early warning of pre-congestion on the new route, then causes early warning of pre-congestion on the new route, then
admission control based on pre-congestion notification will ensure admission control based on pre-congestion notification will ensure
new flows will not be admitted until enough existing flows have new flows will not be admitted until enough existing flows have
departed. Re-routing may result in heavy (pre-)congestion, when the departed. Re-routing may result in heavy (pre-)congestion, when the
flow termination mechanism will kick in. flow termination mechanism will kick in.
If a PCN-boundary-node fails then we would like the regular QoS If a PCN-boundary-node fails then we would like the regular QoS
signalling protocol to take care of things. As an example signalling protocol to take care of things. As an example
[I-D.briscoe-tsvwg-cl-architecture] considers what happens if RSVP is [I-D.briscoe-tsvwg-cl-architecture] considers what happens if RSVP is
the QoS signalling protocol. The details for a specific signalling the QoS signalling protocol.
protocol are out of scope of the PCN WG, however there is a WG
Milestone on generic "Requirements for signalling".
6. Design goals and challenges 6. Design goals and challenges
Prior work on PCN and similar mechanisms has thrown up a number of Prior work on PCN and similar mechanisms has thrown up a number of
considerations about PCN's design goals (things PCN should be good considerations about PCN's design goals (things PCN should be good
at) and some issues that have been hard to solve in a fully at) and some issues that have been hard to solve in a fully
satisfactory manner. Taken as a whole it represents a list of trade- satisfactory manner. Taken as a whole it represents a list of trade-
offs (it's unlikely that they can all be 100% achieved) and perhaps offs (it's unlikely that they can all be 100% achieved) and perhaps
as evaluation criteria to help an operator (or the IETF) decide as evaluation criteria to help an operator (or the IETF) decide
between options. between options.
skipping to change at page 24, line 21 skipping to change at page 24, line 21
travel along an uncongested path travel along an uncongested path
3. ineffective termination: flows are terminated, however their 3. ineffective termination: flows are terminated, however their
path doesn't travel through the (pre-)congested router(s). path doesn't travel through the (pre-)congested router(s).
Since flow termination is a 'last resort' that protects the Since flow termination is a 'last resort' that protects the
network should over-admission occur, this problem is probably network should over-admission occur, this problem is probably
more important to solve than the other two. more important to solve than the other two.
o ECMP and signalling: It is possible that, in a PCN-domain running o ECMP and signalling: It is possible that, in a PCN-domain running
ECMP, the signalling packets (eg RSVP, NSIS) follow a different ECMP, the signalling packets (eg RSVP, NSIS) follow a different
path than the data packets - it depends on which fields the ECMP path than the data packets, which could matter if the signalling
algorithm uses. This could matter if the signalling packets are packets are used as probes. Whether this is an issue depends on
used as probes. which fields the ECMP algorithm uses; if the ECMP algorithm is
restricted to the source and destination IP addresses, then it
won't be.
o Tunnelling: There are scenarios where tunnelling makes it hard to o Tunnelling: There are scenarios where tunnelling makes it hard to
determine the path in the PCN-domain. The problem, its impact and determine the path in the PCN-domain. The problem, its impact and
the potential solutions are similar to those for ECMP. the potential solutions are similar to those for ECMP.
o Scenarios with only one tunnel endpoint in the PCN domain may make o Scenarios with only one tunnel endpoint in the PCN domain may make
it harder for the PCN-egress-node to gather from the signalling it harder for the PCN-egress-node to gather from the signalling
messages (eg RSVP, NSIS) the identity of the PCN-ingress-node. messages (eg RSVP, NSIS) the identity of the PCN-ingress-node.
o Bi-Directional Sessions: Many applications have bi-directional o Bi-Directional Sessions: Many applications have bi-directional
skipping to change at page 26, line 38 skipping to change at page 26, line 41
node. Another possibility is that a probe packet is a signalling node. Another possibility is that a probe packet is a signalling
packet that is anyway travelling from the PCN-ingress-node to the packet that is anyway travelling from the PCN-ingress-node to the
PCN-egress-node (eg an RSVP PATH message travelling from source to PCN-egress-node (eg an RSVP PATH message travelling from source to
destination). destination).
7.2. Probing functions 7.2. Probing functions
The probing functions are: The probing functions are:
o Make decision that probing is needed. As described above, this is o Make decision that probing is needed. As described above, this is
when the ingress-egress-aggregate or the ECMP path carries no PCN- when the ingress-egress-aggregate (or the ECMP path - Section 6)
traffic. An alternative is always to probe, ie probe before carries no PCN-traffic. An alternative is always to probe, ie
admitting every PCN-flow. probe before admitting every PCN-flow.
o (if required) Communicate the request that probing is needed - the o (if required) Communicate the request that probing is needed - the
PCN-egress-node signals to the PCN-ingress-node that probing is PCN-egress-node signals to the PCN-ingress-node that probing is
needed needed
o (if required) Generate probe traffic - the PCN-ingress-node o (if required) Generate probe traffic - the PCN-ingress-node
generates the probe traffic. The appropriate number (or rate) of generates the probe traffic. The appropriate number (or rate) of
probe packets will depend on the PCN-marking algorithm; for probe packets will depend on the PCN-marking algorithm; for
example an excess-rate-marking algorithm generates fewer PCN-marks example an excess-rate-marking algorithm generates fewer PCN-marks
than a threshold-marking algorithm, and so will need more probe than a threshold-marking algorithm, and so will need more probe
skipping to change at page 29, line 34 skipping to change at page 29, line 40
be able to disambiguate a probe packet from a data packet, via the be able to disambiguate a probe packet from a data packet, via the
characteristic setting of particular bit(s) in the packet's header characteristic setting of particular bit(s) in the packet's header
or body - but these bit(s) mustn't be used by any PCN-interior- 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, node's ECMP algorithm. In the general case this isn't possible,
but it should be OK for a typical ECMP algorithm which examines: but it should be OK for a typical ECMP algorithm which examines:
the source and destination IP addresses and port numbers, the the source and destination IP addresses and port numbers, the
protocol ID and the DSCP. protocol ID and the DSCP.
The third viewpoint assumes the following: The third viewpoint assumes the following:
o Simply admitting the new flow has a significant risk of leading to
overload, because the PCN-domain reaches out towards the end
terminals where link capacity is low.
o Every admission control decision involves probing, using the o Every admission control decision involves probing, using the
signalling set-up message as the probe packet (eg RSVP PATH). signalling set-up message as the probe packet (eg RSVP PATH).
o The PCN-marking behaviour is such that every packet is PCN-marked o The PCN-marking behaviour is such that every packet is PCN-marked
if the flow should be blocked, hence only a single probing packet if the flow should be blocked, hence only a single probing packet
is needed. is needed.
The first point breaks Assumption 3 (aggregation) and hence means This viewpoint [I-D.draft-babiarz-pcn-3sm] has in particular been
that this viewpoint is out of scope of the initial Charter of the PCN suggested for the scenario where the PCN-domain reaches out towards
WG. the end terminals (note that it's assumed the trust and aggregation
assumptions still hold), although it has also been suggested for
other scenarios.
8. Operations and Management 8. Operations and Management
This Section considers operations and management issues, under the This Section considers operations and management issues, under the
FCAPS headings: OAM of Faults, Configuration, Accounting, Performance FCAPS headings: OAM of Faults, Configuration, Accounting, Performance
and Security. Provisioning is discussed with performance. and Security. Provisioning is discussed with performance.
8.1. Configuration OAM 8.1. Configuration OAM
This architecture document predates the detailed standards actions of This architecture document predates the detailed standards actions of
the PCN WG. Here we assume that only interoperable PCN-marking the PCN WG. Here we assume that only interoperable PCN-marking
behaviours will be standardised, otherwise we would have to consider behaviours will be standardised, otherwise we would have to consider
how to avoid interactions between non-interoperable marking how to avoid interactions between non-interoperable marking
behaviours. However, more diversity in edge-node behaviours is behaviours. However, more diversity in PCN-boundary-node behaviours
expected, in order to interface with diverse industry architectures. is expected, in order to interface with diverse industry
architectures. It may be possible to have different PCN-boundary-
node behaviours for different ingress-egress-aggregates within the
same PCN-domain.
PCN functionality is configured on either the egress or the ingress
interfaces of PCN-nodes. A consistent choice must be made across the
PCN-domain to ensure that the PCN mechanisms protect all links.
PCN configuration control variables fall into the following PCN configuration control variables fall into the following
categories: categories:
o system options (enabling or disabling behaviours) o system options (enabling or disabling behaviours)
o parameters (setting levels, addresses etc) o parameters (setting levels, addresses etc)
All configurable variables will need to sit within an SNMP management One possibility is that all configurable variables sit within an SNMP
framework [RFC3411], being structured within a defined management management framework [RFC3411], being structured within a defined
information base (MIB) on each node, and being remotely readable and management information base (MIB) on each node, and being remotely
settable via a suitably secure management protocol (SNMPv3). readable and settable via a suitably secure management protocol
(SNMPv3).
Some configuration options and parameters have to be set once to Some configuration options and parameters have to be set once to
'globally' control the whole PCN-domain. Where possible, these are 'globally' control the whole PCN-domain. Where possible, these are
identified below. This may affect operational complexity and the identified below. This may affect operational complexity and the
chances of interoperability problems between kit from different chances of interoperability problems between kit from different
vendors. vendors.
It may be possible for an operator to configure some PCN-interior-
nodes so they don't run the PCN mechanisms, if it knows that these
links will never become (pre-)congested.
8.1.1. System options 8.1.1. System options
On PCN-interior-nodes there will be very few system options: On PCN-interior-nodes there will be very few system options:
o Whether two PCN-markings (based on the PCN-lower-rate and PCN- o Whether two PCN-markings (based on the PCN-lower-rate and PCN-
upper-rate) are enabled or only one (see Section 4.3). Typically upper-rate) are enabled or only one (see Section 4.3). Typically
all nodes throughout a PCN-domain will be configured the same in all nodes throughout a PCN-domain will be configured the same in
this respect. However, exceptions could be made. For example, if this respect. However, exceptions could be made. For example, if
most PCN-nodes used both markings, but some legacy hardware was most PCN-nodes used both markings, but some legacy hardware was
incapable of running two algorithms, an operator might be willing incapable of running two algorithms, an operator might be willing
skipping to change at page 32, line 5 skipping to change at page 32, line 20
their network so that it can cope with a failure of any single PCN- their network so that it can cope with a failure of any single PCN-
node without terminating any flows. node without terminating any flows.
Setting these rates on first deployment of PCN will be very similar Setting these rates on first deployment of PCN will be very similar
to the traditional process for sizing an admission controlled to the traditional process for sizing an admission controlled
network, depending on: the operator's requirements for minimising network, depending on: the operator's requirements for minimising
flow blocking (grade of service), the expected PCN traffic load on flow blocking (grade of service), the expected PCN traffic load on
each link and its statistical characteristics (the traffic matrix), each link and its statistical characteristics (the traffic matrix),
contingency for re-routing the PCN traffic matrix in the event of contingency for re-routing the PCN traffic matrix in the event of
single or multiple failures and the expected load from other classes single or multiple failures and the expected load from other classes
relative to link capacities. But once a domain is up and running, a relative to link capacities [Menth]. But once a domain is up and
PCN design goal is to be able to determine growth in these configured running, a PCN design goal is to be able to determine growth in these
rates much more simply, by monitoring PCN-marking rates from actual configured rates much more simply, by monitoring PCN-marking rates
rather than expected traffic (see Section 8.2 on Performance & from actual rather than expected traffic (see Section 8.2 on
Provisioning). Performance & Provisioning).
Operators may also wish to configure a rate greater than the PCN- Operators may also wish to configure a rate greater than the PCN-
upper-rate that is the absolute maximum rate that a link allows for upper-rate that is the absolute maximum rate that a link allows for
PCN-traffic. This may simply be the physical link rate, but some PCN-traffic. This may simply be the physical link rate, but some
operators may wish to configure a logical limit to prevent starvation operators may wish to configure a logical limit to prevent starvation
of other traffic classes during any brief period after PCN-traffic of other traffic classes during any brief period after PCN-traffic
exceeds the PCN-upper-rate but before flow termination brings it back exceeds the PCN-upper-rate but before flow termination brings it back
below this rate. below this rate.
Specific marking algorithms will also depend on further configuration Specific marking algorithms will also depend on further configuration
skipping to change at page 34, line 37 skipping to change at page 35, line 7
Section 5.9 describes how the PCN architecture has been designed to Section 5.9 describes how the PCN architecture has been designed to
ensure admitted flows continue gracefully after recovering ensure admitted flows continue gracefully after recovering
automatically from link or node failures. The need to record and automatically from link or node failures. The need to record and
monitor re-routing events affecting signalling is unchanged by the monitor re-routing events affecting signalling is unchanged by the
addition of PCN to a DiffServ domain. Similarly, re-routing events addition of PCN to a DiffServ domain. Similarly, re-routing events
within the PCN-domain will be recorded and monitored just as they within the PCN-domain will be recorded and monitored just as they
would be without PCN. would be without PCN.
PCN-marking does make it possible to record 'near-misses'. For PCN-marking does make it possible to record 'near-misses'. For
instance, at the PCN-egress-node a 'reporting threshold' could be set instance, at the PCN-egress-node a 'reporting threshold' could be set
to monitor how often the system comes close to triggering flow to monitor how often - and for how long - the system comes close to
blocking without actually doing so. Similarly, bursts of flow triggering flow blocking without actually doing so. Similarly,
termination marking could be recorded even if they are not bursts of flow termination marking could be recorded even if they are
sufficiently sustained to trigger flow termination. Such statistics not sufficiently sustained to trigger flow termination. Such
could be correlated with per-queue counts of marking volume (Section statistics could be correlated with per-queue counts of marking
8.2) to upgrade resources in danger of causing service degradation, volume (Section 8.2) to upgrade resources in danger of causing
or to trigger manual tracing of intermittent incipient errors that service degradation, or to trigger manual tracing of intermittent
would otherwise have gone unnoticed. incipient errors that would otherwise have gone unnoticed.
Finally, of course, many faults are caused by failings in the Finally, of course, many faults are caused by failings in the
management process ('human error'): a wrongly configured address in a management process ('human error'): a wrongly configured address in a
node, a wrong address given in a signalling protocol, a wrongly node, a wrong address given in a signalling protocol, a wrongly
configured parameter in a queueing algorithm, a node set into a configured parameter in a queueing algorithm, a node set into a
different mode from other nodes, and so on. Generally, a clean different mode from other nodes, and so on. Generally, a clean
design with few configurable options ensures this class of faults can design with few configurable options ensures this class of faults can
be traced more easily and prevented more often. Sound management be traced more easily and prevented more often. Sound management
practice at run-time also helps. For instance: a management system practice at run-time also helps. For instance: a management system
should be used that constrains configuration changes within system should be used that constrains configuration changes within system
skipping to change at page 36, line 24 skipping to change at page 36, line 42
functionality between PCN-interior-nodes and PCN-boundary-nodes, and functionality between PCN-interior-nodes and PCN-boundary-nodes, and
the security considerations are somewhat different for each, mainly the security considerations are somewhat different for each, mainly
because PCN-boundary-nodes are flow-aware and PCN-interior-nodes are because PCN-boundary-nodes are flow-aware and PCN-interior-nodes are
not. not.
o because the PCN-boundary-nodes are flow-aware, they are trusted to o because the PCN-boundary-nodes are flow-aware, they are trusted to
use that awareness correctly. The degree of trust required use that awareness correctly. The degree of trust required
depends on the kinds of decisions they have to make and the kinds depends on the kinds of decisions they have to make and the kinds
of information they need to make them. For example when the PCN- of information they need to make them. For example when the PCN-
boundary-node needs to know the contents of the sessions for boundary-node needs to know the contents of the sessions for
making the admission and termination decisions (perhaps based on making the admission and termination decisions, or when the
the MLPP precedence), or when the contents are highly classified, contents are highly classified, then the security requirements for
then the security requirements for the PCN-boundary-nodes involved the PCN-boundary-nodes involved will also need to be high.
will also need to be high.
o the PCN-ingress-nodes police packets to ensure a flow sticks o the PCN-ingress-nodes police packets to ensure a PCN-flow sticks
within its agreed limit, and to ensure that only flows which have within its agreed limit, and to ensure that only PCN-flows which
been admitted contribute PCN-traffic into the PCN-domain. The have been admitted contribute PCN-traffic into the PCN-domain.
policer must drop (or perhaps re-mark to a different DSCP) any The policer must drop (or perhaps re-mark to a different DSCP) any
PCN-packets received that are outside this remit. This is similar PCN-packets received that are outside this remit. This is similar
to the existing IntServ behaviour. Between them the PCN-boundary- to the existing IntServ behaviour. Between them the PCN-boundary-
nodes must encircle the PCN-domain, otherwise PCN-packets could nodes must encircle the PCN-domain, otherwise PCN-packets could
enter the PCN-domain without being subject to admission control, enter the PCN-domain without being subject to admission control,
which would potentially destroy the QoS of existing flows. which would potentially destroy the QoS of existing flows.
o PCN-interior-nodes aren't flow-aware. This prevents some security o PCN-interior-nodes aren't flow-aware. This prevents some security
attacks where an attacker targets specific flows in the data plane attacks where an attacker targets specific flows in the data plane
- for instance for DoS or eavesdropping. - for instance for DoS or eavesdropping.
skipping to change at page 37, line 26 skipping to change at page 37, line 44
[I-D.behringer-tsvwg-rsvp-security-groupkeying] may also be [I-D.behringer-tsvwg-rsvp-security-groupkeying] may also be
useful; for a generic signalling protocol the PCN WG document on useful; for a generic signalling protocol the PCN WG document on
"Requirements for signalling" will describe the requirements in "Requirements for signalling" will describe the requirements in
more detail. more detail.
Operational security advice is given in Section 8.5. Operational security advice is given in Section 8.5.
11. Conclusions 11. Conclusions
The document describes a general architecture for flow admission and The document describes a general architecture for flow admission and
termination based on aggregated pre-congestion information in order termination based on pre-congestion information in order to protect
to protect the quality of service of established inelastic flows the quality of service of established inelastic flows within a single
within a single DiffServ domain. The main topic is the functional DiffServ domain. The main topic is the functional architecture
architecture (first covered at a high level and then at a greater (first covered at a high level and then at a greater level of
level of detail). It also mentions other topics like the assumptions detail). It also mentions other topics like the assumptions and open
and open issues. issues.
12. Acknowledgements 12. Acknowledgements
This document is a revised version of [I-D.eardley-pcn-architecture]. This document is a revised version of [I-D.eardley-pcn-architecture].
Its authors were: P. Eardley, J. Babiarz, K. Chan, A. Charny, R. Its authors were: P. Eardley, J. Babiarz, K. Chan, A. Charny, R.
Geib, G. Karagiannis, M. Menth, T. Tsou. They are therefore Geib, G. Karagiannis, M. Menth, T. Tsou. They are therefore
contributors to this document. contributors to this document.
Thanks to those who've made comments on Thanks to those who've made comments on
[I-D.eardley-pcn-architecture] and on earlier versions of this draft: [I-D.eardley-pcn-architecture] and on earlier versions of this draft:
Lachlan Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake, Lachlan Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake,
Bob Briscoe, Ken Carlberg, Anna Charny, Joachim Charzinski, Andras Bob Briscoe, Ken Carlberg, Anna Charny, Joachim Charzinski, Andras
Csaszar, Lars Eggert, Ruediger Geib, Robert Hancock, Georgios Csaszar, Lars Eggert, Ruediger Geib, Robert Hancock, Ingemar
Karagiannis, Michael Menth, Tom Taylor, Tina Tsou, Delei Yu. Thanks Johansson, Georgios Karagiannis, Michael Menth, Tom Taylor, Hannes
to Bob Briscoe who extensively revised the Operations and Management Tschofenig, Tina Tsou, Magnus Westerlund, Delei Yu. Thanks to Bob
Briscoe who extensively revised the Operations and Management
section. section.
This document is the result of discussions in the PCN WG and This document is the result of discussions in the PCN WG and
forerunner activity in the TSVWG. A number of previous drafts were forerunner activity in the TSVWG. A number of previous drafts were
presented to TSVWG: [I-D.chan-pcn-problem-statement], presented to TSVWG: [I-D.chan-pcn-problem-statement],
[I-D.briscoe-tsvwg-cl-architecture], [I-D.briscoe-tsvwg-cl-phb], [I-D.briscoe-tsvwg-cl-architecture], [I-D.briscoe-tsvwg-cl-phb],
[I-D.charny-pcn-single-marking], [I-D.babiarz-pcn-sip-cap], [I-D.charny-pcn-single-marking], [I-D.babiarz-pcn-sip-cap],
[I-D.lefaucheur-rsvp-ecn], [I-D.westberg-pcn-load-control]. The [I-D.lefaucheur-rsvp-ecn], [I-D.westberg-pcn-load-control]. The
authors of them were: B, Briscoe, P. Eardley, D. Songhurst, F. Le authors of them were: B, Briscoe, P. Eardley, D. Songhurst, F. Le
Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley, G. Karagiannis, Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley, G. Karagiannis,
A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G. Liu, A. Bhargava. A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G. Liu, A. Bhargava.
13. Comments Solicited 13. Comments Solicited
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF PCN working group mailing list <pcn@ietf.org>. addressed to the IETF PCN working group mailing list <pcn@ietf.org>.
14. Changes 14. Changes
Changes from -01 to -02: 14.1. 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 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).
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.
14.2. Changes from -01 to -02
o S1: Benefits: provisioning bullet extended to stress that PCN does o S1: Benefits: provisioning bullet extended to stress that PCN does
not use RFC2475-style traffic conditioning. not use RFC2475-style traffic conditioning.
o S1: Deployment models: mentioned, as variant of PCN-domain o S1: Deployment models: mentioned, as variant of PCN-domain
extending to end nodes, that may extend to LAN edge switch. extending to end nodes, that may extend to LAN edge switch.
o S3.1: Trust Assumption: added note about not needing PCN-marking o S3.1: Trust Assumption: added note about not needing PCN-marking
capability if known that an interface cannot become pre-congested. capability if known that an interface cannot become pre-congested.
skipping to change at page 39, line 9 skipping to change at page 40, line 31
o S5.8: Tunnelling: added case of "partially PCN-capable tunnel" and o S5.8: Tunnelling: added case of "partially PCN-capable tunnel" and
degraded bullet on this in S6 (Open Issues) degraded bullet on this in S6 (Open Issues)
o S7: Probing: new section. Much more comprehensive than old S5.5. o S7: Probing: new section. Much more comprehensive than old S5.5.
o S8: Operations and Management: substantially revised. o S8: Operations and Management: substantially revised.
o other minor changes not affecting semantics o other minor changes not affecting semantics
Changes from -00 to -01: 14.3. Changes from -00 to -01
In addition to clarifications and nit squashing, the main changes In addition to clarifications and nit squashing, the main changes
are: are:
o S1: Benefits: added one about provisioning (and contrast with o S1: Benefits: added one about provisioning (and contrast with
DiffServ SLAs) DiffServ SLAs)
o S1: Benefits: clarified that the objective is also to stop PCN- o S1: Benefits: clarified that the objective is also to stop PCN-
packets being significantly delayed (previously only mentioned not packets being significantly delayed (previously only mentioned not
dropping packets) dropping packets)
skipping to change at page 40, line 28 skipping to change at page 42, line 4
of scope for this document" and edited a couple of sentences that of scope for this document" and edited a couple of sentences that
were close to solution space. were close to solution space.
o S6: Open issues: added one about scenarios with only one tunnel o S6: Open issues: added one about scenarios with only one tunnel
endpoint in the PCN domain . endpoint in the PCN domain .
o S6: Open issues: ECMP: added under-admission as another potential o S6: Open issues: ECMP: added under-admission as another potential
risk risk
o S6: Open issues: added one about "Silent at start" o S6: Open issues: added one about "Silent at start"
o S10: Conclusions: a small conclusions section added
o S10: Conclusions: a small conclusions section added. 15. Appendix A: Possible work items beyond the scope of the current PCN
WG Charter
15. Informative References 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 is
deployed on the general Internet (ie widely but not universally
deployed).
o applying the PCN mechanisms to other types of traffic, ie beyond
inelastic traffic. For instance, applying the PCN mechanisms to
traffic scheduled with the Assured Forwarding per-hop behaviour.
One example could be flow-rate adaptation by elastic applications,
that adapts according to the pre-congestion information.
o the aggregation assumption doesn't hold, because the link capacity
is too low. Measurement-based admission control is then risky.
o the applicability of PCN mechanisms for emergency use (911, GETS,
WPS, MLPP, etc.)
Other possibilities include:
o indicating pre-congestion through signalling messages rather than
in-band (in the form of PCN-marked packets)
o the decision-making functionality is at a centralised node rather
than at the PCN-boundary-nodes. This requires that the PCN-
egress-node signals PCN-feedback-information to the centralised
node, and that the centralised node signals to the PCN-ingress-
node about the decision about admission (or termination). It may
also need the centralised node and the PCN-boundary-nodes to know
each others addresses. It would be possible for the centralised
node to be one of the PCN-boundary-nodes, when clearly the
signalling would sometimes be replaced by a message internal to
the node.
o It would be possible for the centralised node to be one of the
PCN-boundary-nodes, when clearly the signalling would sometimes be
replaced by a message internal to the node.
o signalling extensions for specific protocols (eg RSVP, NSIS). For
example: the details of how the signalling protocol installs the
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 if it is necessary to carry ECN
marks transparently. Note: There is a PCN WG Milestone on
"Requirements for signalling", which is potential input for the
appropriate WGs.
o policing by the PCN-ingress-node may not be needed if the PCN-
domain can trust that the upstream network has already policed the
traffic on its behalf.
o PCN for Pseudowire: PCN may be used as a congestion avoidance
mechanism for edge to edge pseudowire emulations
[I-D.ietf-pwe3-congestion-frmwk].
o PCN for MPLS: [RFC3270] defines how to support the DiffServ
architecture in MPLS networks. [RFC5129] describes how to add PCN
for admission control of microflows into a set of MPLS aggregates
(Multi-protocol label switching). PCN-marking is done in MPLS's
EXP field.
o PCN for Ethernet: Similarly, it may be possible to extend PCN into
Ethernet networks, where PCN-marking is done in the Ethernet
header.
.
16. Informative References
[I-D.briscoe-tsvwg-cl-architecture] [I-D.briscoe-tsvwg-cl-architecture]
Briscoe, B., "An edge-to-edge Deployment Model for Pre- Briscoe, B., "An edge-to-edge Deployment Model for Pre-
Congestion Notification: Admission Control over a Congestion Notification: Admission Control over a
DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04
(work in progress), October 2006. (work in progress), October 2006.
[I-D.briscoe-tsvwg-cl-phb] [I-D.briscoe-tsvwg-cl-phb]
Briscoe, B., "Pre-Congestion Notification marking", Briscoe, B., "Pre-Congestion Notification marking",
draft-briscoe-tsvwg-cl-phb-03 (work in progress), draft-briscoe-tsvwg-cl-phb-03 (work in progress),
skipping to change at page 41, line 27 skipping to change at page 44, line 49
[I-D.ietf-tsvwg-admitted-realtime-dscp] [I-D.ietf-tsvwg-admitted-realtime-dscp]
"DSCPs for Capacity-Admitted Traffic", November 2006, <htt "DSCPs for Capacity-Admitted Traffic", November 2006, <htt
p://www.ietf.org/internet-drafts/ p://www.ietf.org/internet-drafts/
ietf-tsvwg-admitted-realtime-dscp-02.txt>. ietf-tsvwg-admitted-realtime-dscp-02.txt>.
[I-D.briscoe-tsvwg-ecn-tunnel] [I-D.briscoe-tsvwg-ecn-tunnel]
"Layered Encapsulation of Congestion Notification", "Layered Encapsulation of Congestion Notification",
June 2007, <http://www.ietf.org/internet-drafts/ June 2007, <http://www.ietf.org/internet-drafts/
briscoe-tsvwg-ecn-tunnel-00.txt>. briscoe-tsvwg-ecn-tunnel-00.txt>.
[I-D.ietf-tsvwg-ecn-mpls]
"Explicit Congestion Marking in MPLS", October 2007, <http
://www.ietf.org/internet-drafts/
draft-ietf-tsvwg-ecn-mpls-02.txt>.
[I-D.charny-pcn-single-marking] [I-D.charny-pcn-single-marking]
"Pre-Congestion Notification Using Single Marking for "Pre-Congestion Notification Using Single Marking for
Admission and Termination", November 2007, <http:// Admission and Termination", November 2007, <http://
www.ietf.org/internet-drafts/ www.ietf.org/internet-drafts/
draft-charny-pcn-single-marking-03.txt>. draft-charny-pcn-single-marking-03.txt>.
[I-D.eardley-pcn-architecture] [I-D.eardley-pcn-architecture]
"Pre-Congestion Notification Architecture", June 2007, <ht "Pre-Congestion Notification Architecture", June 2007, <ht
tp://www.ietf.org/internet-drafts/ tp://www.ietf.org/internet-drafts/
draft-eardley-pcn-architecture-00.txt>. draft-eardley-pcn-architecture-00.txt>.
[I-D.westberg-pcn-load-control] [I-D.westberg-pcn-load-control]
"LC-PCN: The Load Control PCN Solution", November 2007, <h "LC-PCN: The Load Control PCN Solution", November 2007, <h
ttp://www.ietf.org/internet-drafts/ ttp://www.ietf.org/internet-drafts/
draft-westberg-pcn-load-control-02.txt>. draft-westberg-pcn-load-control-02.txt>.
[I-D.behringer-tsvwg-rsvp-security-groupkeying] [I-D.behringer-tsvwg-rsvp-security-groupkeying]
"A Framework for RSVP Security Using Dynamic Group "Applicability of Keying Methods for RSVP Security",
Keying", June 2007, <http://www.watersprings.org/pub/id/ November 2007, <http://www.watersprings.org/pub/id/
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt>. draft-behringer-tsvwg-rsvp-security-groupkeying-01.txt>.
[I-D.briscoe-re-pcn-border-cheat] [I-D.briscoe-re-pcn-border-cheat]
"Emulating Border Flow Policing using Re-ECN on Bulk "Emulating Border Flow Policing using Re-ECN on Bulk
Data", June 2006, <http://www.watersprings.org/pub/id/ Data", June 2006, <http://www.watersprings.org/pub/id/
briscoe-re-pcn-border-cheat-01.txt>. 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)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
skipping to change at page 42, line 47 skipping to change at page 46, line 22
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002. Services", RFC 3270, May 2002.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", Services in the Internet Architecture: an Overview",
RFC 1633, June 1994. RFC 1633, June 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000. RFC 2983, October 2000.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. December 2002.
skipping to change at page 43, line 49 skipping to change at page 47, line 21
[P.800] "Methods for subjective determination of transmission [P.800] "Methods for subjective determination of transmission
quality", ITU-T Recommendation P.800, August 1996. quality", ITU-T Recommendation P.800, August 1996.
[Songhurst] [Songhurst]
"Guaranteed QoS Synthesis for Admission Control with "Guaranteed QoS Synthesis for Admission Control with
Shared Capacity", BT Technical Report TR-CXR9-2006-001, Shared Capacity", BT Technical Report TR-CXR9-2006-001,
Feburary 2006, <http://www.cs.ucl.ac.uk/staff/B.Briscoe/ Feburary 2006, <http://www.cs.ucl.ac.uk/staff/B.Briscoe/
projects/ipe2eqos/gqs/papers/GQS_shared_tr.pdf>. 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] [PCN-email-ECMP]
"Email to PCN WG mailing list", November 2007, <http:// "Email to PCN WG mailing list", November 2007, <http://
www1.ietf.org/mail-archive/web/pcn/current/msg00871.html>. www1.ietf.org/mail-archive/web/pcn/current/msg00871.html>.
[PCN-email-traffic-empty-aggregates] [PCN-email-traffic-empty-aggregates]
"Email to PCN WG mailing list", October 2007, <http:// "Email to PCN WG mailing list", October 2007, <http://
www1.ietf.org/mail-archive/web/pcn/current/msg00831.html>. www1.ietf.org/mail-archive/web/pcn/current/msg00831.html>.
Author's Address Author's Address
Philip Eardley Philip Eardley
BT BT
B54/77, Sirius House Adastral Park Martlesham Heath B54/77, Sirius House Adastral Park Martlesham Heath
Ipswich, Suffolk IP5 3RE Ipswich, Suffolk IP5 3RE
United Kingdom United Kingdom
Email: philip.eardley@bt.com Email: philip.eardley@bt.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 103 change blocks. 
313 lines changed or deleted 479 lines changed or added

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