Network Working Group P. Eardley, Ed.
Request for Comments: 5670 BT
Category: Standards Track November 2009
Metering and Marking Behaviour of PCN-Nodes
Abstract
The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain
in a simple, scalable, and robust fashion. This document defines the
two metering and marking behaviours of PCN-nodes. Threshold-metering
and -marking marks all PCN-packets if the rate of PCN-traffic is
greater than a configured rate ("PCN-threshold-rate"). Excess-
traffic-metering and -marking marks a proportion of PCN-packets, such
that the amount marked equals the rate of PCN-traffic in excess of a
configured rate ("PCN-excess-rate"). The level of marking allows
PCN-boundary-nodes to make decisions about whether to admit or
terminate PCN-flows.
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
Eardley Standards Track [Page 1]
RFC 5670 PCN metering and marking November 2009
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction ....................................................2
1.1. Terminology ................................................4
1.1.1. Requirements Language ...............................5
2. Specified PCN-Metering and -Marking Behaviours ..................5
2.1. Behaviour Aggregate Classification Function ................5
2.2. Dropping Function ..........................................5
2.3. Threshold-Meter Function ...................................6
2.4. Excess-Traffic-Meter Function ..............................6
2.5. Marking Function ...........................................7
3. Security Considerations .........................................7
4. Acknowledgements ................................................8
5. References ......................................................8
5.1. Normative Reference ........................................8
5.2. Informative References .....................................8
Appendix A. Example Algorithms ...................................11
A.1. Threshold-Metering and -Marking ...........................11
A.2. Excess-Traffic-Metering and -Marking ......................12
Appendix B. Implementation Notes .................................13
B.1. Competing-Non-PCN-Traffic .................................13
B.2. Scope .....................................................14
B.3. Behaviour Aggregate Classification ........................15
B.4. Dropping ..................................................15
B.5. Threshold-Metering ........................................17
B.6. Excess-Traffic-Metering ...................................18
B.7. Marking ...................................................19
1. Introduction
The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain
in a simple, scalable, and robust fashion. Two mechanisms are used:
admission control to decide whether to admit or block a new flow
request, and (in abnormal circumstances) flow termination to decide
whether to terminate some of the existing flows. To achieve this,
the overall rate of PCN-traffic is metered on every link in the
domain, and PCN-packets are appropriately marked when certain
configured rates are exceeded. These configured rates are below the
rate of the link, thus providing notification to boundary nodes about
Eardley Standards Track [Page 2]
RFC 5670 PCN metering and marking November 2009
overloads before any congestion occurs (hence "Pre-Congestion
Notification"). The level of marking allows boundary nodes to make
decisions about whether to admit or terminate. Within the domain,
PCN-traffic is forwarded in a prioritised Diffserv traffic class
[RFC2475].
This document defines the two metering and marking behaviours of PCN-
nodes. Their aim is to enable PCN-nodes to give an "early warning"
of potential congestion before there is any significant build-up of
PCN-packets in their queues. In summary, their objectives are:
o Threshold-metering and -marking: to mark all PCN-packets (with a
"threshold-mark") when the bit rate of PCN-traffic is greater than
its configured reference rate ("PCN-threshold-rate").
o Excess-traffic-metering and -marking: when the bit rate of PCN-
packets is greater than its configured reference rate ("PCN-
excess-rate"), to mark PCN-packets (with an "excess-traffic-mark")
at a rate equal to the difference between the rate of PCN-traffic
and the PCN-excess-rate.
Note that although [RFC3168] defines a broadly RED-like (Random Early
Detection) default congestion marking behaviour, it allows
alternatives to be defined; this document defines such an
alternative.
Section 2 below describes the functions involved, which in outline
(see Figure 1) are:
o Behaviour aggregate (BA) classification: decide whether or not an
incoming packet is a PCN-packet.
o Dropping (optional): drop packets if the link is overloaded.
o Threshold-meter: determine whether the bit rate of PCN-traffic
exceeds its configured reference rate (PCN-threshold-rate). The
meter operates on all PCN-packets on the link, and not on
individual flows.
o Excess-traffic-meter: measure by how much the bit rate of PCN-
traffic exceeds its configured reference rate (PCN-excess-rate).
The meter operates on all PCN-packets on the link, and not on
individual flows.
o PCN-mark: actually mark the PCN-packets, if the meter functions
indicate to do so.
Eardley Standards Track [Page 3]
RFC 5670 PCN metering and marking November 2009
+---------+ Result
+->|Threshold|-------+
| | Meter | |
| +---------+ V
+----------+ +- - - - -+ | +------+
| BA | | | | | | Marked
Packet ⇒|Classifier|=⇒| Dropper |==?==============⇒|Marker|=⇒ Packet
Stream | | | | | | | Stream
+----------+ +- - - - -+ | +------+
| +---------+ ^
| | Excess | |
+->| Traffic |-------+
| Meter | Result
+---------+
Figure 1: Schematic of PCN-interior-node functionality
Appendix A gives an example of algorithms that fulfil the
specification of Section 2, and Appendix B provides some explanations
of and comments on Section 2. Both the Appendices are informative.
The general architecture for PCN is described in [RFC5559], whilst
[Menth10] is an overview of PCN.
1.1. Terminology
In addition to the terminology defined in [RFC5559] and [RFC2474],
the following terms are defined:
o Competing-non-PCN-packet: a non-PCN-packet that shares a link with
PCN-packets and competes with them for its forwarding bandwidth.
Competing-non-PCN-packets MUST NOT be PCN-marked (only PCN-packets
can be PCN-marked).
Note: In general, it is not advised to have any competing-non-PCN-
traffic.
Note: There is likely to be traffic (such as best effort) that is
forwarded at lower priority than PCN-traffic; although it shares
the link with PCN-traffic, it doesn't compete for forwarding
bandwidth, and hence it is not competing-non-PCN-traffic. See
Appendix B.1 for further discussion about competing-non-PCN-
traffic.
Eardley Standards Track [Page 4]
RFC 5670 PCN metering and marking November 2009
o Metered-packet: a packet that is metered by the metering functions
specified in Sections 2.3 and 2.4. A PCN-packet MUST be treated
as a metered-packet (with the minor exception noted below in
Section 2.4). A competing-non-PCN-packet MAY be treated as a
metered-packet.
1.1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Specified PCN-Metering and -Marking Behaviours
This section defines the two PCN-metering and -marking behaviours.
The descriptions are functional and are not intended to restrict the
implementation. The informative Appendices supplement this section.
2.1. Behaviour Aggregate Classification Function
A PCN-node MUST classify a packet as a PCN-packet if the value of its
Differentiated Services Code Point (DSCP) and Explicit Congestion
Notification (ECN) fields correspond to a PCN-enabled codepoint, as
defined in the encoding scheme applicable to the PCN-domain (for
example, [RFC5696] defines the baseline encoding). Otherwise, the
packet MUST NOT be classified as a PCN-packet.
A PCN-node MUST classify a packet as a competing-non-PCN-packet if it
is not a PCN-packet and it competes with PCN-packets for its
forwarding bandwidth on a link.
2.2. Dropping Function
Note: If the PCN-node's queue overflows, then naturally packets are
dropped. This section describes additional action.
On all links in the PCN-domain, dropping MAY be done by first
metering all metered-packets to determine if the rate of metered-
traffic on the link is greater than the rate allowed for such
traffic; if the rate of metered-traffic is too high, then drop
metered-packets.
If the PCN-node drops PCN-packets, then:
o PCN-packets that arrive at the PCN-node already excess-traffic-
marked SHOULD be preferentially dropped.
Eardley Standards Track [Page 5]
RFC 5670 PCN metering and marking November 2009
o the PCN-node's excess-traffic-meter SHOULD NOT meter the PCN-
packets that it drops.
2.3. Threshold-Meter Function
A PCN-node MUST implement a threshold-meter that has behaviour
functionally equivalent to the following.
The meter acts like a token bucket, which is sized in bits and has a
configured reference rate (bits per second). The amount of tokens in
the token bucket is termed F_tm. Tokens are added at the reference
rate (PCN-threshold-rate), to a maximum value BS_tm. Tokens are
removed equal to the size in bits of the metered-packet, to a minimum
F_tm = 0. (Explanation of abbreviations: F is short for Fill of the
token bucket, BS for bucket size, and tm for threshold-meter.)
The token bucket has a configured intermediate depth, termed
threshold. If F_tm < threshold, then the meter indicates to the
marking function that the packet is to be threshold-marked;
otherwise, it does not.
2.4. Excess-Traffic-Meter Function
A packet SHOULD NOT be metered (by this excess-traffic-meter
function) in the following two cases:
o if the PCN-packet is already excess-traffic-marked on arrival at
the PCN-node.
o if this PCN-node drops the packet.
Otherwise, the PCN-packet MUST be treated as a metered-packet -- that
is, it is metered by the excess-traffic-meter.
A PCN-node MUST implement an excess-traffic-meter. The excess-
traffic-meter SHOULD indicate packets to be excess-traffic-marked,
independent of their size ("packet size independent marking"); if
"packet size independent marking" is not implemented, then the
excess-traffic-meter MUST use the "classic" metering behaviour.
For the "classic" metering behaviour, the excess-traffic-meter has
behaviour functionally equivalent to the following.
The meter acts like a token bucket, which is sized in bits and has a
configured reference rate (bits per second). The amount of tokens in
the token bucket is termed F_etm. Tokens are added at the reference
rate (PCN-excess-rate), to a maximum value BS_etm. Tokens are
removed equal to the size in bits of the metered-packet, to a minimum
Eardley Standards Track [Page 6]
RFC 5670 PCN metering and marking November 2009
F_etm = 0. If the token bucket is empty (F_etm = 0), then the meter
indicates to the marking function that the packet is to be excess-
traffic-marked. (Explanation of abbreviations: F is short for Fill
of the token bucket, BS for bucket size, and etm for excess-traffic-
meter.)
For "packet size independent marking", the excess-traffic-meter has
behaviour functionally equivalent to the following.
The meter acts like a token bucket, which is sized in bits and has a
configured reference rate (bits per second). The amount of tokens in
the token bucket is termed F_etm. Tokens are added at the reference
rate (PCN-excess-rate), to a maximum value BS_etm. If the token
bucket is not negative, then tokens are removed equal to the size in
bits of the metered-packet (and the meter does not indicate to the
marking function that the packet is to be excess-traffic-marked). If
the token bucket is negative (F_etm < 0), then the meter indicates to
the marking function that the packet is to be excess-traffic-marked
(and no tokens are removed). (Explanation of abbreviations: F is
short for Fill of the token bucket, BS for bucket size, and etm for
excess-traffic-meter.)
Otherwise, the meter MUST NOT indicate marking.
2.5. Marking Function
A PCN-packet MUST be marked to reflect the metering results by
setting its encoding state appropriately, as specified by the
specific encoding scheme that applies in the PCN-domain. A
consistent choice of encoding scheme MUST be made throughout a PCN-
domain.
A PCN-node MUST NOT:
o PCN-mark a packet that is not a PCN-packet;
o change a non-PCN-packet into a PCN-packet;
o change a PCN-packet into a non-PCN-packet.
Note: Although competing-non-PCN-packets MAY be metered, they MUST
NOT be PCN-marked.
3. Security Considerations
It is assumed that all PCN-nodes are PCN-enabled and are trusted for
truthful PCN-metering and PCN-marking. If this isn't the case, then
there are numerous potential attacks. For instance, a rogue PCN-
Eardley Standards Track [Page 7]
RFC 5670 PCN metering and marking November 2009
interior-node could PCN-mark all packets so that no flows were
admitted. Another possibility is that it doesn't PCN-mark any
packets, even when it is pre-congested.
Note that PCN-interior-nodes are not flow-aware. This prevents some
security attacks where an attacker targets specific flows in the data
plane -- for instance, for Denial-of-Service (DoS) or eavesdropping.
As regards Security Operations and Management, PCN adds few specifics
to the general good practice required in this field [RFC4778]. For
example, it may be sensible for a PCN-node to raise an alarm if it is
persistently PCN-marking.
Security considerations are further discussed in [RFC5559].
4. Acknowledgements
This document is the result of extensive collaboration within the PCN
WG. Amongst the most active other contributors to the development of
the ideas specified in this document have been Jozef Babiarz, Bob
Briscoe, Kwok-Ho Chan, Anna Charny, Georgios Karagiannis, Michael
Menth, Toby Moncaster, Daisuke Satoh, and Joy Zhang. Appendix A is
based on text from Michael Menth.
This document is a development of [Briscoe06-2]. Its authors are
therefore also contributors to this document: Jozef Babiarz, Attila
Bader, Bob Briscoe, Kwok-Ho Chan, Anna Charny, Stephen Dudley, Philip
Eardley, Georgios Karagiannis, Francois Le Faucheur, Vassilis
Liatsos, Dave Songhurst, and Lars Westberg.
Thanks to those who've made comments on the document: Joe Babiarz,
Fred Baker, David Black, Bob Briscoe, Ken Carlberg, Anna Charny,
Ralph Droms, Mehmet Ersue, Adrian Farrel, Ruediger Geib, Wei Gengyu,
Fortune Huang, Christian Hublet, Ingemar Johansson, Georgios
Karagiannis, Alexey Melnikov, Michael Menth, Toby Moncaster, Dimitri
Papadimitriou, Tim Polk, Daisuke Satoh, and Magnus Westerlund.
5. References
5.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informative References
[Baker08] Baker, F., Polk, J., and M. Dolly, "DSCP for Capacity-
Admitted Traffic", Work in Progress, November 2008.
Eardley Standards Track [Page 8]
RFC 5670 PCN metering and marking November 2009
[Briscoe06-1] Briscoe, B., Eardley, P., Songhurst, D., Le Faucheur,
F., Charny, A., Babiarz, J., Chan, K., Dudley, S.,
Karagiannis, G., Bader, A., and L. Westberg, "An edge-
to-edge Deployment Model for Pre-Congestion
Notification: Admission Control over a DiffServ
Region", Work in Progress, October 2006.
[Briscoe06-2] Briscoe, B., Eardley, P., Songhurst, D., Le Faucheur,
F., Charny, A., Liatsos, V., Babiarz, J., Chan, K.,
Dudley, S., Karagiannis, G., Bader, A., and L.
Westberg, "Pre-Congestion Notification marking", Work
in Progress, October 2006.
[Briscoe08] Briscoe, B., "Byte and Packet Congestion
Notification", Work in Progress, August 2008.
[Charny07] Charny, A., Babiarz, J., Menth, M., and X. Zhang,
"Comparison of Proposed PCN Approaches", Work
in Progress, November 2007.
[Menth10] Menth, M., Lehrieder, F., Briscoe, B., Eardley, P.,
Moncaster, T., Babiarz, J., Chan, K., Charny, A.,
Karagiannis, G., Zhang, X., Taylor, T., Satoh, D., and
R. Geib, "A Survey of PCN-Based Admission Control and
Flow Termination", IEEE Communications Surveys and
Tutorials, 2010 (third issue), <http://
www3.informatik.uni-wuerzburg.de/staff/menth/
Publications/papers/Menth08-PCN-Overview.pdf>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RFC4778] Kaeo, M., "Operational Security Current Practices in
Internet Service Provider Environments", RFC 4778,
January 2007.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
DiffServ Service Classes", RFC 5127, February 2008.
Eardley Standards Track [Page 9]
RFC 5670 PCN metering and marking November 2009
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009.
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information",
RFC 5696, November 2009.
[Taylor09] Charny, A., Huang, F., Menth, M., and T. Taylor, "PCN
Boundary Node Behaviour for the Controlled Load (CL)
Mode of Operation", Work in Progress, March 2009.
Eardley Standards Track [Page 10]
RFC 5670 PCN metering and marking November 2009
Appendix A. Example Algorithms
Note: This Appendix is informative, not normative. It is an example
of algorithms that implement Section 2 and is based on [Charny07] and
[Menth10].
There is no attempt to optimise the algorithms. The metering and
marking functions are implemented together. It is assumed that three
encoding states are available (one for threshold-marked, one for
excess-traffic-marked, and one for not-marked). It is assumed that
all metered-packets are PCN-packets and that the link is never
overloaded. For excess-traffic-marking, "packet size independent
marking" applies.
A.1. Threshold-Metering and -Marking
A token bucket with the following parameters:
A PCN-packet has the following parameters:
In addition there is the parameter:
now: the current time (seconds)
The following steps are performed when a PCN-packet arrives on a
link:
rate); add tokens to token bucket
* F_tm = max(0, F_tm - packet_size); remove tokens from token
bucket
Eardley Standards Track [Page 11]
RFC 5670 PCN metering and marking November 2009