Internet DRAFT - draft-taylor-pcn-piggyback-edge-behaviour
draft-taylor-pcn-piggyback-edge-behaviour
Internet Engineering Task Force T. Taylor, Ed.
Internet-Draft Huawei Technologies
Intended status: Informational October 19, 2009
Expires: April 22, 2010
The PCN Piggybacking Edge Behaviour
draft-taylor-pcn-piggyback-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 April 22, 2010.
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.
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 RFC 5559. This memo
Taylor Expires April 22, 2010 [Page 1]
Internet-Draft Piggybacking Edge Behaviour October 2009
describes a behaviour for PCN egress nodes known as the
"piggybacking" edge behaviour, because it "piggybacks" PCN
information in resource signalling messages. This version of the
memo describes two alternatives, where piggybacking is derived from
the CL edge behaviour and where it is derived from the SM edge
behaviour. The SM and CL edge behaviours are specified in companion
documents.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Measurement Behaviour . . . . . . . . . . . . . . . . . . . . . 3
3. Assumed Domain Behaviour . . . . . . . . . . . . . . . . . . . 4
4. Egress Node Behaviour . . . . . . . . . . . . . . . . . . . . . 4
5. Ingress Node Behaviour . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Taylor Expires April 22, 2010 [Page 2]
Internet-Draft Piggybacking Edge Behaviour October 2009
1. Introduction
The main objective of Pre-Congestion Notification (PCN) is to support
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 and flow termination. Admission control
is used to decide whether to admit or block a new flow request, while
flow termination is used in abnormal circumstances to decide whether
to terminate some of the existing flows. To support these two
features 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
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. For more details see
[RFC5559].
The CL and SM edge node behaviours, described in
[I-D.CL-edge-behaviour] and [I-D.SM-edge-behaviour], specify
assumptions on the marking behaviour within the PCN domain, the
measurements to be taken at ingress and egress nodes respectively,
and the processing of those measurements to allow the making of flow
admisssion and flow termination decisions. In both edge behaviours,
the decision point for individual flows is either the ingress node or
a centralized policy server. This document specifies an edge
behaviour where the admission decision for individual flows is taken
at the egress node. This is accomplished by using resource
signalling (e.g., RSVP) to carry the per-flow decision back to the
ingress node for enforcement. Flow termination requires input from
both the ingress node and egress node, hence the resource signalling
is also used to carry part of the necessary information from the
egress node to the ingress node. This usage of resource signalling
for the additional purpose of carrying PCN measurement data is the
reason for calling this the "piggybacking" edge behaviour.
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. Measurement Behaviour
The ingress and egress nodes to a PCN domain have particular roles to
play in supporting the PCN mechanisms. These are described in
general terms in [RFC5559]. This edge behaviour specification
Taylor Expires April 22, 2010 [Page 3]
Internet-Draft Piggybacking Edge Behaviour October 2009
assumes that both ingress and egress nodes meter PCN traffic
continuously. Based on this metering, the ingress node periodically
calculates and records the rate of PCN traffic it admits to each
ingress-egress aggregate, in octets per second. Similarly, the
egress node periodically calculates and records the rate of PCN
traffic it receives from each ingress-egress aggregate, in octets per
second. In both of the scenarios considered below, it records the
rate of traffic received in PCN-unmarked packets and in PCN-excess-
marked packets. In the CL-like behaviour scenario, it also records
the rate of traffic received in PCN-threshold-marked packets.
3. Assumed Domain Behaviour
The key assumption made in the piggybacking edge behaviour is that
resource availabilty for flow admission is determined through the use
of resource signalling (e.g., RSVP) to reserve resources along the
flow path. It is assumed that for flows within a given ingress-
egress aggregate, all such signalling passes through the ingress and
egress nodes defining the aggregate, in both directions.
Beyond this, this specification considers two alternative scenarios.
In the CL-like scenario, three-state PCN marking is used, so that
packets arriving at the egress node may be PCN-unmarked, PCN-
threshold-marked, or PCN-excess-marked. Marking behaviour is as
specified in [I-D.CL-edge-behaviour]. In the SM-like scenario, two-
state PCN marking is used, so that packets arriving at the egress
node may be PCN-unmarked or PCN-excess-marked only. Marking
behaviour is as specified in [I-D.CL-edge-behaviour].
4. Egress Node Behaviour
As each new set of measurements becomes available, the egress node
calculates the ratio of PCN-unmarked octets to total PCN traffic
received subtracts this ratio from 1, and updates an exponentially-
smoothed average of the result. That is:
New ratio = 1 - (Unmarked traffic rate / Total traffic rate)
New smoothed average = w * new ratio + (1-w) * old smoothed
average
where w is a suitable smoothing weight. See simulation results
documented in TBD for reasonable values of w.
The egress node compares the new smoothed average to a pre-configured
threshold to determine its current admission state. If the smoothed
Taylor Expires April 22, 2010 [Page 4]
Internet-Draft Piggybacking Edge Behaviour October 2009
average exceeds the threshold, the egress node enters "block" state
until the next set of measurements becomes available. If the
smoothed average does not exceed the configured threshold, the egress
node is in "admit" state until the next set of measurements becomes
available.
Each time the egress node processes a resource signalling message
where the egress node will propagate the message toward the ingress
node, the egress node consults its current admission state. If the
admission state is "admit", the egress node propagates the resource
signalling without any further action beyond that required by the
signalling system itself. If the admission state is "block", the
egress node adds an indication in the message it propagates that
resources are unavailable for the flow being signalled. It also adds
two numbers to the message: the latest measured rate of total PCN
traffic received, and the rate of PCN-excess-marked traffic received,
both in octets per second.
5. Ingress Node Behaviour
Ingress node behaviour with respect to admission is the same for both
the CL-like and the SM-like scenario. The ingress node admits the
new flow if the returning resource signalling message indicates
resources available, and blocks it if the returning resource
signalling message indicates that insufficient resources are
unavailable.
Behaviour with respect to flow termination differs slightly between
the two scenarios. Flow termination is considered in either case
only if the received resource signalling message indicates not only
that insufficient resources are available to admit the flow, but also
reports a non-zero level of excess-marked traffic. If these
conditions are satisfied:
o in the CL-like scenario, the ingress node computes an estimate of
the edge-to-edge supportable rate of PCN traffic equal to the
difference between the total traffic rate reported in the resource
signalling message and the PCN-excess-marked traffic rate.
o in the SM-like scenario the ingress node calculates the difference
between the total traffic rate reported in the resource signalling
message and the PCN-excess-marked traffic rate, but then computes
an estimate of the edge-to-edge supportable rate of PCN traffic
equal to this difference multiplied by a pre-configured factor U,
which is the same for all ingress-egress aggregates.
The ingress node terminates flows amounting to a total traffic rate
Taylor Expires April 22, 2010 [Page 5]
Internet-Draft Piggybacking Edge Behaviour October 2009
equal to the difference between the most-recently measured rate of
admitted PCN traffic at the ingress node and the estimate of the
edge-to-edge supportable rate calculated as just described. In the
CL-like case, termination is always required if the preconditions for
this calculation have been met. In the SM-like case, termination may
not be required.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
To be written.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.CL-edge-behaviour]
Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
Taylor, Ed., "PCN Boundary Node Behaviour for the
Controlled Load (CL) Mode of Operation (Work in
progress)", 2009.
[I-D.SM-edge-behaviour]
Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T.
Taylor, Ed., "PCN Boundary Node Behaviour for the Single
Marking (SM) Mode of Operation (Work in progress)", 2009.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009.
Appendix A. Additional Stuff
This becomes an Appendix.
Taylor Expires April 22, 2010 [Page 6]
Internet-Draft Piggybacking Edge Behaviour October 2009
Author's Address
Tom Taylor (editor)
Huawei Technologies
1852 Lorraine Ave
Ottawa
Canada
Email: tom111.taylor@bell.net
Taylor Expires April 22, 2010 [Page 7]
