Internet Engineering Task Force T. Taylor, Ed.
Internet-Draft Huawei Technologies
Intended status: Informational March 8, 2010
Expires: September 9, 2010
The PCN Piggybacking Edge Behaviour
draft-taylor-pcn-piggybacking-edge-behaviour-01
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
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.
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 9, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Taylor Expires September 9, 2010 [Page 1]
Internet-Draft Piggybacking Edge Behaviour March 2010
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Assumed Signalling Behaviour . . . . . . . . . . . . . . . . . 4
3. Assumed Behaviour at Interior Nodes . . . . . . . . . . . . . . 4
4. Edge Node Behaviours . . . . . . . . . . . . . . . . . . . . . 4
4.1. Egress Node Behaviour . . . . . . . . . . . . . . . . . . . 4
4.1.1. Data Collection . . . . . . . . . . . . . . . . . . . . 4
4.1.2. Reporting . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Ingress Node Behaviour . . . . . . . . . . . . . . . . . . 6
4.3. Decision Point Behaviour . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Taylor Expires September 9, 2010 [Page 2]
Internet-Draft Piggybacking Edge Behaviour March 2010
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 decisions to be made
about whether to admit or terminate individual flows. For more
details see [RFC5559].
Boundary node behaviours specify a detailed set of algorithms and
edge node behaviours used to implement the PCN mechanisms. The
piggybacking edge behaviour which is the subject of this memo
introduces no new behaviours and algorithms beyond those provided by
the SM and CL edge behaviours ([I-D.SM-Edge-Behaviour] and
[I-D.CL-Edge-Behaviour] respectively). Instead, it provides an
alternative method of signalling whereby the egress node reports the
rates it has calculated as an addition to resource signalling rather
than using a separate protocol. This has implications both for the
operation of the resource signalling and the operation of the PCN
mechanisms.
1.1. Terminology
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].
In addition to the terms defined in [RFC5559], this document uses the
following terms:
decision point
The node that makes the decision about which flows to admit and to
terminate. In a given network deployment, this may be the ingress
node or a centralized control node. Decisions are enforced by the
ingress node. In contrast to the signalling architecture
considered in [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour],
in the piggybacking case the egress node always sends its
information to the ingress node rather than the decision point.
The ingress node then forwards the PCN reports to the decision
Taylor Expires September 9, 2010 [Page 3]
Internet-Draft Piggybacking Edge Behaviour March 2010
point if they are not collocated. The decision point returns its
decisions to the ingress node as usual.
NM-Rate, ThM-Rate, ETM-Rate
The calculated rate at which PCN traffic has been received in
unmarked packets, threshold-marked packets (CL mode only), and
excess-traffic-marked packets respectively. See the descriptions
of egress node behaviour in [I-D.SM-Edge-Behaviour] and
[I-D.CL-Edge-Behaviour] for further details.
2. Assumed Signalling Behaviour
For the piggybacking edge behaviour, it is assumed that applications
are using a resource signalling protocol (e.g., RSVP, NSIS) to
request resources from the network. The PCN domain is viewed as a
building block in the complete end-to-end path. Resource signalling
is processed by the edge nodes of the PCN domain, but not by the
interior nodes. Thus the passage from the PCN-ingress-node to the
PCN-egress-node or vice versa is viewed as a single hop.
It is assumed that a request for resources for a given flow requires
at least one message passing through the PCN-egress-node toward the
PCN-ingress-node. This is consistent with RSVP and some cases of
NSIS, but rules out "Basic Sender Initiated Reservation" as described
in Section 4.1 of [I-D.NSLP].
3. Assumed Behaviour at Interior Nodes
It is assumed that nodes interior to the PCN domain do not
participate in the resource signalling, but simply forward that
signalling toward the edge. Beyond that, the applicable assumptions
are as described in [I-D.SM-Edge-Behaviour] and
[I-D.CL-Edge-Behaviour] respectively.
4. Edge Node Behaviours
4.1. Egress Node Behaviour
4.1.1. Data Collection
The PCN-egress-node MUST meter received PCN traffic per ingress-
egress-aggregate and periodically calculate the rate at which
unmarked, threshold-marked (for the CL behaviour), and excess-
traffic-marked traffic is received, all as described in
[I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour] respectively.
Taylor Expires September 9, 2010 [Page 4]
Internet-Draft Piggybacking Edge Behaviour March 2010
The interval between successive calculations SHOULD be a constant
value of the order of 100 to 500 ms, as described in the CL and SM
documents.
If so configured, when operating in CL mode, the PCN-egress-node MUST
also save the identities of flows experiencing excess-traffic-marking
during the latest measurement interval.
4.1.2. Reporting
The PCN-egress-node reports its measured results according to the
following rules:
o When the PCN-egress-node receives resource signalling for a new
flow, it processes that message according to the rules of the
protocol. However, if the message is to be forwarded in the
direction of the PCN-ingress-node, the egress node MUST add to the
message an object containing its latest calculated values of NM-
rate, ThM-Rate (for CL mode only) and ETM-Rate for the ingress-
egress-aggregate which that flow would join. In addition, if
operating in CL mode and so configured, if the ETM-Rate is greater
than zero the PCN-egress-node SHOULD add to the message an object
identifying individual flows within the aggregate that experienced
excess-traffic marking.
There may not be space for this within the message.
o If the PCN-egress-node receives resource signalling refreshing
state for an established flow, it again processes the message
according to the rules of the protocol. OPEN ISSUE: Should it
attach the latest values of the calculated rates, or should it
attach the values that were placed into the original message
establishing that flow? The latter was suggested by
[I-D.lefaucheur-rsvp-ecn], to make it easier for implementations
to distinguish refresh messages.
o If the calculated ETM-Rate for an interval is greater than zero
and no resource signalling in the direction of the PCN-ingress-
node was received during that interval relating to the ingress-
egress-aggregate concerned, the PCN-egress-node SHOULD generate an
autonomous report identifying the ingress-egress-aggregate, giving
the calculated values of NM-Rate, ThM-Rate, and ETM-Rate, and, if
so configured, a list of individual flows that were excess-
traffic-marked in the interval just concluded.
The condition of no message in the right direction in the
previous interval is a heuristic for predicting whether one
will come along in the next interval.
Taylor Expires September 9, 2010 [Page 5]
Internet-Draft Piggybacking Edge Behaviour March 2010
OPEN ISSUE 1: can this use a message within the resource
protocol? RSVP messages are associated with individual flows.
Can an RSVP session between ingress and egress be set up
specifically for the aggregate, so that messages like this
relate to the aggregate as a whole?
OPEN ISSUE 2: does the message have to be delivered reliably?
4.2. Ingress Node Behaviour
When the PCN-ingress-node receives resource signalling from the
direction of the PCN-egress-node, it processes the message as
required by the resource protocol. Before forwarding it, it removes
any PCN-related information added by the egress node and forwards
that information to the decision point.
If the ingress node and the decision point are collocated, the
exchanges between them are an internal operation.
The PCN-ingress-node MUST provide the estimated current rate of
admitted PCN traffic (octets per second) for a specific ingress-
egress-aggregate when the decision point requests it, as described in
[I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour].
4.3. Decision Point Behaviour
Behaviour at the decision point is exactly as documented in
[I-D.SM-Edge-Behaviour] or [I-D.CL-Edge-Behaviour] as applicable.
5. Acknowledgements
draft-lefaucheur-rsvp-ecn-01.txt ([I-D.lefaucheur-rsvp-ecn]) covered
this ground in much greater detail, three and a half years ago. The
author borrowed some of the information from that document, but the
document itself should probably be revised to fit the present shape
of PCN if there is interest in this work.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
To be written.
Taylor Expires September 9, 2010 [Page 6]
Internet-Draft Piggybacking Edge Behaviour March 2010
8. References
8.1. Normative 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)", 2010.
[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)", 2010.
[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.NSLP]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling (Work in progress)",
January 2010.
[I-D.lefaucheur-rsvp-ecn]
Le Faucheur, F., Charny, A., Briscoe, B., Eardley, P.,
Chan, K., and J. Babiarz, "RSVP Extensions for Admission
Control over Diffserv using Pre-congestion Notification
(PCN) (Work in progress)", June 2006.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009.
Author's Address
Tom Taylor (editor)
Huawei Technologies
1852 Lorraine Ave
Ottawa
Canada
Email: tom111.taylor@bell.net
Taylor Expires September 9, 2010 [Page 7]