Internet Engineering Task Force A. Charny
Internet-Draft Cisco Systems
Intended status: Informational F. Huang
Expires: September 3, 2009 Huawei Technologies
M. Menth
University of Wuerzburg
T. Taylor, Ed.
Huawei Technologies
March 2, 2009
PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of
Operation
draft-taylor-pcn-cl-edge-behaviour-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2009.
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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Charny, et al. Expires September 3, 2009 [Page 1]
Internet-Draft PCN CL Boundary Node Behaviour March 2009
Abstract
Precongestion notification (PCN) is a means for protecting quality of
service for inelastic traffic admitted to a Diffserv domain. The
overall PCN architecture is described in ID.PCNArch. This memo is
one of a series describing possible boundary node behaviours for a
PCN domain. The behaviour described here is that for three-state
measurement-based load control, known informally as CL. The
requirement for three encoding states means that CL is for
experimental use only pending further standards action.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Assumed Core Network Behaviour for CL . . . . . . . . . . . . 4
3. Node Behaviours . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Measurement Requirements . . . . . . . . . . . . . . . . . 5
3.2. Decision-Making Behaviour . . . . . . . . . . . . . . . . 6
3.2.1. Determining Whether Flow Termination Is Required . . . 6
3.2.2. Estimating the Amount of Traffic To Terminate . . . . 7
3.2.3. Flow Admission Decisions . . . . . . . . . . . . . . . 7
4. Assumed Signalling Flows . . . . . . . . . . . . . . . . . . . 8
4.1. Assumed Signalling To Support Classification . . . . . . . 8
4.2. Assumed Signalling Of Measurements . . . . . . . . . . . . 8
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Operation With Standalone PCN-Decision-Node . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Charny, et al. Expires September 3, 2009 [Page 2]
Internet-Draft PCN CL Boundary Node Behaviour March 2009
1. Introduction
Precongestion notification (PCN) is a means for protecting quality of
service (QoS) for inelastic traffic admitted to a Diffserv domain.
The overall PCN architecture is described in [ID.PCNArch]. In the
general case, QoS is protected by restricting admission of PCN-
traffic to the PCN-domain when precongestion indications are first
detected. In the case of catastrophic failures or a sudden increase
in traffic offered by admitted flows, QoS is protected by terminating
PCN-flows to the point where traffic falls to a level which appears
to be supportable in current conditions. Detection of congestion
status, the making of admission decisions, and the making of
termination decisions are all done on the basis of the ingress-
egress-aggregate as defined in [ID.PCNArch].
Boundary node behaviours specify how the PCN-ingress-node and PCN-
egress-node make use of the PCN mechanisms to achieve QoS protection.
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 [RFC2119].
1.2. Terminology
In addition to the terms defined in [ID.PCNArch], this document uses
the following terms:
o Measurement period - the period of time over which a measurement
or set of measurements is accumulated.
o PCN-sent-traffic - the total PCN-traffic, measured in octets per
period, that is admitted to a given ingress-egress-aggregate by
the PCN-ingress-node.
o Edge-to-edge supportable rate of PCN-traffic - the maximum rate of
PCN-traffic that can be carried through the PCN network for a
given ingress-egress-aggregate at a given moment of time.
Estimated by the rate of PCN-traffic received at the egress node
without excess-traffic-marking during measurement periods in which
excess-traffic-marked packets are received.
o PCN-decision-node - the node that makes admission and flow
termination decisions based on an evaluation of the traffic
measurements for a given ingress-egress aggregate. The main body
of this document assumes that the PCN-decision-node is the same as
the PCN-ingress-node. Appendix A considers the alternative where
Charny, et al. Expires September 3, 2009 [Page 3]
Internet-Draft PCN CL Boundary Node Behaviour March 2009
the PCN-decision-node is a separate entity.
1.3. Summary
The remainder of this document describes the assumed core node
behaviour for the CL mode, the behaviour of the ingress and egress
nodes, the signalling requirements between the nodes, and the
deployment considerations specific to the CL mode. As mentioned
already, Appendix A describes the operation of CL mode when the PCN-
decision-node is separate from the PCN-ingress-node.
2. Assumed Core Network Behaviour for CL
This section describes the assumed behaviour for nodes of the PCN-
domain when acting in their role as PCN-interior-nodes. The CL mode
of operation assumes that:
o encoding of PCN status within individual packets is based on
[ID.PCN-baseline], extended to provide a third encoding state.
Possible extensions for this purpose are documented in
[ID.PCN3state] or alternatively [ID.PCN3in1];
o the domain satisfies the conditions specified in the applicable
extension document;
o each link has been configured with a PCN-threshold-rate having a
value equal to the PCN-admissible-rate for the link;
o each link has been configured with a PCN-excess-rate having a
value equal to the PCN-supportable-rate for the link;
o PCN-interior-nodes perform threshold-marking and excess-traffic-
marking of packets according to the rules specified in
[ID.PCN-marking], and any additional rules specified in the
applicable extension document;
According to [ID.PCN-baseline], the extension documents should
specify the allowable transitions between marking states. However,
to be absolutely clear, these allowable transitions are specified
here. At any interior node, the only permitted transitions are
these:
o a PCN packet which is not marked (NM) MAY be threshold-marked
(ThM) or excess-traffic-marked (ETM);
o a PCN packet which is threshold-marked (ThM) MAY be excess-
traffic-marked (ETM).
Charny, et al. Expires September 3, 2009 [Page 4]
Internet-Draft PCN CL Boundary Node Behaviour March 2009
An interior node MUST NOT re-mark a packet from PCN to non-PCN, or
vice versa.
3. Node Behaviours
3.1. Measurement Requirements
[We need to think about the units. Will octet counts exceed 2 ** 32
per second?]
For each ingress-egress-aggregate, the egress node MUST continuously
measure the following quantities:
o NM-count: number of octets of PCN-traffic contained in received
packets which are neither threshold-marked nor excess-traffic-
marked;
o ThM-count: number of octets of PCN-traffic contained in received
packets which are threshold-marked;
o ETM-count: number of octets of PCN-traffic contained in received
packets which are excess-traffic-marked.
The egress node MUST capture its observations as octet counts per
measurement period but convert them to rates (octets per second) for
reporting purposes. The egress node MUST report these quantities to
the ingress node as soon as possible after the end of the measurement
period. The egress node MUST also include the duration D of the
measurement period in milliseconds in this report.
To avoid measurement bias, successive measurement periods MUST be of
the same duration, and the end of one measurement period MUST be the
beginning of the next one, independently of current flow conditions.
It is RECOMMENDED that the length of the measurement period lie
between 100 and 500 ms, to provide a reasonable tradeoff between
signalling demands on the network and the time taken to react to
impending congestion.
Note that, according to the logic presented in the next section,
the choice of measurement period duration also determines the
increment of time during which a policy of "admit" or "block"
persists for new flows offered to the ingress-egress-aggregate.
The ingress node MUST determine the current rate of PCN-sent-traffic
(octets per second) through measurement, but only when it receives a
report for a given ingress-egress-aggregate that contains a non-zero
count of excess-marked packets. It MAY do this by measuring
Charny, et al. Expires September 3, 2009 [Page 5]
Internet-Draft PCN CL Boundary Node Behaviour March 2009
continuously and recording observations per measurement period in the
same way as the egress node, then selecting the rate calculated for
the most recent measurement period. See Section 3.2.2 for how this
quantity is used to calculate the amount of traffic to be terminated.
3.2. Decision-Making Behaviour
This section describes the behaviour required to make decisions on
when to admit flows, when to block them, and when to terminate flows
already admitted, for a given ingress-egress-aggregate. This is the
role of the PCN-decision-node, which in the main body of this memo is
assumed to coincide with the PCN-ingress-node. The decision cycle is
repeated each time a set of measurements is received from the egress
node. The outcome of the decision is a flow termination state (flow
termination required/not required), an admission state (accept or
block new flows), and, when flow termination is required, an estimate
of the amount of traffic that must be terminated. The steps in the
process are as follows:
1. Determine whether flow termination is required.
2. If flow termination is required:
A. Set the admission state to "block".
B. Estimate the amount of traffic that must be terminated.
C. Select currently admitted flows based on policy and terminate
them until the termination quota has been reached.
3. If flow termination is not required, determine whether the
admission state is "admit" or "block".
4. While the admission state is "block", block all new flows offered
to the ingress-egress-aggregate unless policy overrides this
decision for specific flows.
In the next few sections, the symbols NM-rate, ThM-rate, and ETM-rate
designate the rates reported by an egress node for the most recent
measurement period, for unmarked, threshold-marked, and excess-
traffic-marked PCN-traffic respectively.
3.2.1. Determining Whether Flow Termination Is Required
If the value ETM-rate for the measurement period is greater than zero
(i.e., excess-traffic-marked packets were observed), flow termination
is required.
Charny, et al. Expires September 3, 2009 [Page 6]
Internet-Draft PCN CL Boundary Node Behaviour March 2009
3.2.2. Estimating the Amount of Traffic To Terminate
To determine how much traffic to terminate, the ingress node must
first measure the rate of PCN-traffic being sent (octets per second)
as discussed in Section 3.1. Call this quantity the Send-rate.
The estimate of how much traffic to terminate is based on the
assumption that the sum:
NM-rate + ThM-rate
of unmarked and threshold-marked PCN-traffic represents the current
edge-to-edge supportable rate of flow of PCN-traffic. The estimate
of how much traffic to terminate is then the difference:
Send-rate - (NM-rate + ThM-rate).
3.2.3. Flow Admission Decisions
This section describes the logic used to set the flow admission state
in periods when flow termination is not taking place.
Two running estimates ThMavg and Totavg are maintained, of the
average rate of threshold-marked traffic and the average rate of
total traffic received. These estimates MUST NOT be updated in
periods when excess-marked traffic is observed (hence ETM-rate will
be 0 and can be ignored). Because traffic rates will be time-
varying, the average rates SHOULD be calculated using exponential
smoothing, as follows:
ThMavg(updated) = (1-a)*ThMavg(previous) + a*ThM-rate; and
Totavg(updated) = (1-a)*Totavg(previous) + a*(NM-rate + ThM-rate),
The constant a is tuned to provide the optimal tradeoff between
tracking current traffic conditions and eliminating excessive
volatility. The appropriate value is in the order of 1000/D to
3000/D, where D is the reported measurement period duration in
milliseconds.
Following the update of the running estimates the ratio
ThMavg / Totavg
is calculated. If this ratio exceeds a configured decision value (of
the order of 0.5), the admission state MUST be set to "block". If
the ratio is less than or equal to the decision value, the admission
state is set to "admit". The admission state remains in effect until
Charny, et al. Expires September 3, 2009 [Page 7]
Internet-Draft PCN CL Boundary Node Behaviour March 2009
new measurements in the next or a later period cause the ratio to
drop below (rise above, respectively) the decision value.
4. Assumed Signalling Flows
4.1. Assumed Signalling To Support Classification
In all boundary node behaviours, it is necessary for the edge nodes
to be provided with the means to distinguish between the flows for
different ingress-egress-aggregates. The means by which the PCN-
egress-node obtains this information is deployment-dependent. For
instance, if aggregates are passed directly from ingress to egress
using tunnels, the tunnel identifier can be used for packet
classification. Alternatively, ingress and egress may exchange
signalling to provide each other with the necessary classifying
information.
4.2. Assumed Signalling Of Measurements
This memo specifies signalling from egress to ingress to report the
values of NM-rate, ThM-rate, and ETM-rate at the end of each
measurement period, along with the measurement period duration D.
5. Deployment Considerations
Have to pull these together.
6. Security Considerations
[ID.PCNArch] provides a general description of the security
considerations for PCN. This memo introduces no new considerations.
7. IANA Considerations
This memo includes no request to IANA.
8. Acknowledgements
Excluding the appendices, the content of this memo is drawn from
[ID.briscoe-CL]. The authors of that document were Bob Briscoe,
Philip Eardley, and Dave Songhurst of BT, Anna Charny and Francois Le
Faucheur of Cisco, Jozef Babiarz, Kwok Ho Chan, and Stephen Dudley of
Nortel, Giorgios Karagiannis of U. Twente and Ericsson, and Attila
Charny, et al. Expires September 3, 2009 [Page 8]
Internet-Draft PCN CL Boundary Node Behaviour March 2009
Bader and Lars Westberg of Ericsson.
9. References
9.1. Normative References
[ID.PCN-baseline]
Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information (Work
in progress)", 2009.
[ID.PCN-marking]
Eardley, P., "Marking behaviour of PCN-nodes (Work in
progress)", 2008.
[ID.PCNArch]
Eardley, P., "Pre-Congestion Notification (PCN)
Architecture (Work in progress)", 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[ID.PCN3in1]
Briscoe, B., "PCN 3-State Encoding Extension in a single
DSCP (Work in progress)", 2008.
[ID.PCN3state]
Moncaster, T., Briscoe, B., and M. Menth, "A three state
extended PCN encoding scheme (Work in progress)", 2008.
[ID.briscoe-CL]
Briscoe, B., "An edge-to-edge Deployment Model for Pre-
Congestion Notification: Admission Control over a
DiffServ Region (expired Internet Draft)", 2006.
Appendix A. Operation With Standalone PCN-Decision-Node
This Appendix describes a mode of operation that falls outside the
current charter of the PCN Working Group, but reflects an
architecture being considered by the ITU-T.
If the PCN-decision node is a separate entity, the following
modifications apply to the description in the main body of this memo:
Charny, et al. Expires September 3, 2009 [Page 9]
Internet-Draft PCN CL Boundary Node Behaviour March 2009
o The PCN-egress-node reports its measurements to the PCN-decision-
node rather than the PCN-ingress-node. As a result, it MAY report
results for multiple ingress-egress-aggregates at once, suitably
labelled, if their measurement periods all end at the same time.
o When the PCN-decision-node receives a report that indicates a non-
zero rate of excess-traffic-marking, it must acquire the value of
Send-rate from the PCN-ingress node in order to calculate how much
traffic to terminate. It may do this by sending a request and
receiving the value in a response. Alternatively, the PCN-
ingress-node may measure PCN-sent-traffic continuously and report
Send-rate to the PCN-decision-node at the end of each measurement
period for each ingress-egress-aggregate it deals with. The
appropriate approach is an open issue.
o The PCN-decision-node selects the flows for termination when this
is required and pushes the necessary policy updates to the PCN-
ingress-node.
o Depending on whether the push or pull model is applicable, the
PCN-decision-node pushes changes to current admission policy for a
given ingress-egress-aggregate to the PCN-ingress-node, or the
PCN-ingress-node requests a decision for each new flow.
Authors' Addresses
Anna Charny
Cisco Systems
300 Apollo Drive
Chelmsford, MA 01824
USA
Email: acharny@cisco.com
Fortune Huang
Huawei Technologies
Section F, Huawei Industrial Base,
Bantian Longgang, Shenzhen 518129
P.R. China
Phone: +86 15013838060
Email: fqhuang@huawei.com
Charny, et al. Expires September 3, 2009 [Page 10]
Internet-Draft PCN CL Boundary Node Behaviour March 2009
Michael Menth
University of Wuerzburg
Am Hubland
Wuerzburg D-97074
Germany
Phone: +49-931-888-6644
Email: menth@informatik.uni-wuerzburg.de
Tom Taylor (editor)
Huawei Technologies
1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8
Canada
Phone: +1 613 680 2675
Email: tom.taylor@rogers.com
Charny, et al. Expires September 3, 2009 [Page 11]