| TOC |
|
By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of 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 23, 2009.
This document standardises the two marking behaviours of PCN-nodes: threshold marking and excess traffic marking. Threshold marking marks all PCN-packets if the PCN traffic rate is greater than its configured rate. Excess traffic marking marks a proportion of PCN-packets, such that the amount marked equals the traffic rate in excess of its configured rate. Setting the configured rates below the physical link rates enables PCN-nodes to provide information to support admission control and flow termination in order to protect the quality of service of established inelastic flows.
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
1.
Introduction
1.1.
Terminology
2.
Specified PCN-marking behaviour
2.1.
Behaviour aggregate classification function
2.2.
Traffic conditioning function
2.3.
Threshold meter function
2.4.
Excess traffic meter function
2.5.
Marking function
3.
IANA Considerations
4.
Security Considerations
5.
Acknowledgements
6.
Changes
6.1.
Changes to -01 from -00
6.2.
Changes to -00
7.
Authors
8.
Informative References
Appendix A.
Example algorithms
A.1.
Threshold metering and marking
A.2.
Excess traffic metering and marking
Appendix B.
Implementation notes
B.1.
Competing-non-PCN-traffic
B.2.
Scope
B.3.
Behaviour aggregate classification
B.4.
Traffic conditioning
B.5.
Threshold metering
B.6.
Excess traffic metering
B.7.
Marking
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
This document standardises the two 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:
[I‑D.ietf‑pcn‑architecture] (Eardley, P., “Pre-Congestion Notification (PCN) Architecture,” April 2009.) describes a general architecture for how, in a particular DiffServ domain, PCN-boundary-nodes convert these PCN-markings into decisions about flow admission and flow termination. Other documents describe the wider per-domain behaviour and how the PCN-markings are encoded in packet headers. PCN encoding uses a combination of the DSCP field and ECN field in the IP header to indicate that a packet is a PCN-packet and whether it is PCN-marked. The baseline encoding [I‑D.ietf‑pcn‑baseline‑encoding] (Moncaster, T., Briscoe, B., and M. Menth, “Baseline Encoding and Transport of Pre-Congestion Information,” September 2009.) standardises two encoding states (PCN-marked and not-marked), whilst other documents define extended schemes with three encoding states (eg [I‑D.moncaster‑pcn‑3‑state‑encoding] (Moncaster, T., Briscoe, B., and M. Menth, “A three state extended PCN encoding scheme,” March 2009.) defines PCN-threshold-marked, PCN-excess-traffic-marked and not-marked). [RFC3168] (Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.) defines a broadly RED-like default congestion marking behaviour, but allows alternatives to be defined; this document defines such an alternative.
Section 2 below specifies the functions involved, which in outline (see Figure 1) are:
+---------+ Result
+->|Threshold|-------+
| | Meter | |
| +---------+ V
+---------+ +- - - - -+ | +------+
| BA | | | | | | Marked
Packet =>|Classify |==>|Condition|==?================>|Marker|==> Packet
Stream | | | | | | | Stream
+---------+ +- - - - -+ | +------+
| +---------+ ^
| | Excess | |
+->| Traffic |-------+
| Meter | Result
+---------+
Figure 1: Schematic of functions for PCN-marking
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.
| TOC |
In addition to the terminology defined in [I‑D.ietf‑pcn‑architecture] (Eardley, P., “Pre-Congestion Notification (PCN) Architecture,” April 2009.) and [RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.), the following terms are defined:
| TOC |
This section specifies the PCN-marking behaviour. The descriptions are functional and are not intended to restrict the implementation. The informative Appendixes supplement it.
| TOC |
A PCN-node MUST classify a packet as a PCN-packet if the value of its DSCP and ECN fields correspond to a PCN-enabled codepoint, as defined in the encoding scheme applicable to the PCN-domain. 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.
| TOC |
Note: if the PCN-node's queue overflows then naturally packets are dropped; traffic conditioning is action additional to this.
On all links in the PCN-domain, traffic conditioning MAY be done by:
If the PCN-node drops PCN-packets then:
| TOC |
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 bit rate, termed PCN-threshold-rate. The amount of tokens in the token bucket is termed TBthreshold.fill. Tokens are added at the PCN-threshold-rate, to a maximum value TBthreshold.max. Tokens are removed equal to the size in bits of the metered-packet, to a minimum TBthreshold.fill=0.
The token bucket has a configured intermediate depth, termed TBthreshold.threshold. If TBthreshold.fill < TBthreshold.threshold, then the meter indicates to the Marking function that the packet is to be threshold-marked; otherwise it does not.
| TOC |
A PCN-packet SHOULD NOT be metered (by this excess traffic meter function) in the following two cases:
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 that has behaviour functionally equivalent to the following.
The meter acts like a token bucket, which is sized in bits and has a configured bit rate, termed PCN-excess-rate. The amount of tokens in the token bucket is termed TBexcess.fill. Tokens are added at the PCN-excess-rate, to a maximum value TBexcess.max. Tokens are removed equal to the size in bits of the metered-packet, to a minimum TBexcess-fill=0. If the token bucket is empty (TBexcess.fill = 0), then the meter indicates to the Marking function that the packet is to be excess-traffic-marked. The PCN-excess-rate is greater than (or equal to) the PCN-threshold-rate.
In addition to the above, if the token bucket is within an MTU of being empty, then the meter SHOULD indicate to the Marking function that the packet is to be excess-traffic-marked; MTU means the maximum size of PCN-packets on the link ("packet size independent marking").
Otherwise the meter MUST NOT indicate marking.
| TOC |
A PCN-node MUST NOT:
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.
| TOC |
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
| TOC |
| TOC |
Michael Menth, Joe Babiarz, Anna Charny reviewed a preliminary version of the draft-eardley-pcn-marking-behaviour-00 draft.
Thanks to those who've made comments on this draft: Michael Menth, Joe Babiarz, Anna Charny, Ruediger Geib, Wei Gengyu, Fortune Huang, Bob Briscoe, Toby Moncaster, Christian Hublet, Ingemar Johansson, Ken Carlberg, Georgios Karagiannis.
All the work by many people in the PCN WG.
| TOC |
| TOC |
Updates as follows:
| TOC |
First version of WG draft, derived from draft-eardley-pcn-marking-behaviour-01, with the following changes:
| TOC |
Many people need to be added.
| TOC |
| TOC |
Note: This Appendix is informative, not normative. It is an example of algorithms that implement Section 2 and is based on [I‑D.charny‑pcn‑comparison] (Charny, A., “Comparison of Proposed PCN Approaches,” November 2007.) and [Menth] (, “Menth,” 2008.).
There is no attempt to optimise the algorithms. It implements the metering and marking functions 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.
| TOC |
A token bucket with the following parameters:
A PCN-packet has the following parameters:
In addition there are the parameters:
The following steps are performed when a PCN-packet arrives on a link:
| TOC |
A token bucket with the following parameters:
A PCN-packet has the following parameters:
In addition there are the parameters:
The following steps are performed when a PCN-packet arrives on a link:
| TOC |
Note: This Appendix is informative, not normative. It comments on Section 2.
| TOC |
In general it is not advised to have any competing-non-PCN-traffic, essentially because the unpredictable amount of competing-non-PCN-traffic makes the PCN mechanisms less accurate and so reduces PCN's ability to protect the QoS of admitted PCN-flows [I‑D.ietf‑pcn‑architecture] (Eardley, P., “Pre-Congestion Notification (PCN) Architecture,” April 2009.). But if there is competing-non-PCN-traffic, then there needs to be:
It is left up to the operator to decide on appropriate action. Traffic conditioning is discussed further in the separate section below.
One specific example of competing-non-PCN-traffic occurs if the PCN-compatible Diffserv codepoint is the Voice-admit codepoint, and there is voice-admit traffic in the PCN-domain.
Another example would occur if there was more than one PCN-compatible Diffserv codepoint in a PCN-domain. For instance, suppose there were two PCN-BAs treated at different priorities. Then as far as the lower priority PCN-BA is concerned, the higher priority PCN-traffic needs to be treated as competing-non-PCN-traffic.
| TOC |
It may be known, eg by the design of the network topology, that some links can never be pre-congested (even in unusual circumstances, eg after the failure of some links). There is then no need to deploy PCN behaviour on those links.
The meter and marker can be implemented on the ingoing or outgoing interface of a PCN-node. It may be that existing hardware can support only one meter and marker per ingoing interface and one per outgoing interface. Then for instance threshold metering and marking could be run on all the ingoing interfaces and excess traffic metering and marking on all the outgoing interfaces; note that the same choice must be made for all the links in a PCN-domain to ensure that the two metering behaviours are applied exactly once for all the links.
Note that even if there are only two encoding states, it is still required that both the meters are implemented, in order to ease compatibility between equipment and remove a configuration option and associated complexity. Hardware with limited availability of token buckets could be configured to run only one of the meters, but it must be possible to enable either meter. Although this scenario means that the Marking function ignores indications from one of the meters, they might be logged or acted upon in some other way, for example by the management system or an explicit signalling protocol; such considerations are out of scope of PCN.
| TOC |
Configuration of PCN-nodes will define what values of the DSCP and ECN fields indicate a PCN-packet in a particular PCN-domain.
Configuration will also define what values of the DSCP and ECN fields indicate a competing-non-PCN-packet in a particular PCN-domain.
| TOC |
If there is no competing-non-PCN-traffic, then it is not expected that traffic conditioning is needed, since PCN's flow admission and termination mechanisms limit the amount of PCN-traffic. Even so, traffic conditioning still might be implemented as a back stop against misconfiguration of the PCN-domain, for instance.
The objective of traffic conditioning is to minimise the queueing delay suffered by metered-traffic at a PCN-node, since PCN-traffic (and perhaps competing-non-PCN-traffic) is expected to be inelastic traffic generated by real time applications. In practice it would be defined as exceeding a specific traffic profile, typically based on a token bucket. The details will depend on how the router's implementation handles the two sorts of traffic [I‑D.ietf‑tsvwg‑admitted‑realtime‑dscp] (Baker, F., Polk, J., and M. Dolly, “DSCP for Capacity-Admitted Traffic,” March 2010.):
The traffic conditioning action is to drop packets (which is often called "policing"). Downgrading of packets to a lower priority BA is left as a theoretical possibility (beware of packet mis-ordering). Shaping ("the process of delaying packets" [RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.)) is not suitable if the traffic comes from real time applications. In general it is reasonable for competing-non-PCN-traffic to get harsher treatment than PCN-traffic (ie competing-non-PCN-packets are preferentially dropped), because PCN's flow admission and termination mechanisms are stronger than the mechanisms that are likely to be applied to the competing-non-PCN-traffic. The PCN mechanisms also mean that a traffic conditioner should not be needed for the PCN-traffic.
Preferential dropping of excess-traffic-marked packets: Section 2.3 specifies: "If the PCN-node drops PCN-packets then ... PCN-packets that arrive at the PCN-node already excess-traffic-marked SHOULD be preferentially dropped". This avoids over-termination, with the CL/SM edge behaviour, in the event of multiple bottlenecks in the PCN-domain [I‑D.charny‑pcn‑comparison] (Charny, A., “Comparison of Proposed PCN Approaches,” November 2007.).
Exactly what "preferentially dropped" means is left to the implementation. It is also left to the implementation what to do if there are no excess-traffic-marked PCN-packets available at a particular instant.
Section 2.2 also specifies: "the PCN-node's Excess traffic Meter SHOULD NOT meter the PCN-packets that it drops." This avoids over-termination [Menth] (, “Menth,” 2008.). Effectively it means that traffic conditioning should be done before the meter functions - which is natural.
| TOC |
The description is in terms of a ‘token bucket with threshold’ (which [I‑D.briscoe‑tsvwg‑cl‑architecture] (Briscoe, B., “An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region,” October 2006.) views as a virtual queue). However the implementation is not standardised.
Section 2.3 defines: "If TBthreshold.fill < TBthreshold.threshold, then the meter indicates to the Marking function that the packet is to be threshold-marked; otherwise it does not." Note that the PCN-packet (that causes the token bucket to cross TBthreshold.threshold) is marked without explicit additional bias for the packet's size.
The behaviour must be functionally equivalent to the description above. "Functionally equivalent" means the observable 'black box' behaviour is the same or very similar. It is intended to allow implementation freedom over matters such as:
similarly, when the token bucket is very nearly full and a packet arrives large than (TBthreshold.max - TBthreshold.fill), then the precise change in TBthreshold.fill is up to the implementation.
| TOC |
The description is in terms of a token bucket, however the implementation is not standardised.
As in Section B.3, "functionally equivalent" allows some implementation flexibility when the token bucket is very nearly empty or very nearly full.
Packet size independent marking is specified as a SHOULD in Section 2.4 ( "if the token bucket is within an MTU of being empty, then the meter SHOULD indicate to the Marking function that the packet is to be excess-traffic-marked; MTU means the maximum size of PCN-packets on the link".) Without it, large packets are more likely to be excess-traffic-marked than small packets and this means that, with some edge behaviours, flows with large packets are more likely to be terminated than flows with small packets [I‑D.briscoe‑tsvwg‑byte‑pkt‑mark] (Briscoe, B., “Byte and Packet Congestion Notification,” February 2008.) [Menth] (, “Menth,” 2008.).
Section 2.4 specifies: "A packet SHOULD NOT be metered (by this excess traffic meter function) ... If the packet is already excess-traffic-marked on arrival at the PCN-node". This avoids over-termination (with some edge behaviours) in the event that the PCN-traffic passes through multiple bottlenecks in the PCN-domain [I‑D.charny‑pcn‑comparison] (Charny, A., “Comparison of Proposed PCN Approaches,” November 2007.). Note that an implementation could determine whether the packet is already excess-traffic-marked as an integral part of its Classification function.
Section 2.4 specifies: "A packet SHOULD NOT be metered (by this excess traffic meter function) ... If this PCN-node drops the packet." This avoids over-termination [Menth] (, “Menth,” 2008.). (A similar statement could also be made for the threshold meter function, but is irrelevant, as a link that is overloaded will already be substantially pre-congested and hence PCN-marking all packets.)
Note that TBexcess.max is independent of TBthreshold.max; TBexcess.fill is independent of TBthreshold.fill (except in that a packet changes both); and the two configured rates, PCN-excess-rate and PCN-threshold-rate are independent (except that PCN-excess-rate >= PCN-threshold-rate).
| TOC |
Section 2.5 defines: "A PCN-node MUST NOT ...change a PCN-packet into a non PCN-packet". This means that a PCN-node MUST NOT traffic condition by downgrading a PCN-packet into a lower priority DiffServ BA. The bullet needs to be modified if the WG decides to allow such traffic conditioning.
Section 2.5 defines: "A PCN-node MUST NOT ...PCN-mark a packet that is not a PCN-packet". This means that in the scenario where competing-non-PCN-packets are treated as metered-packets, a meter may indicate a packet is to be PCN-marked, but the Marking function knows it cannot be marked. It is left open to the implementation exactly what to do in this case; one simple possibility is to mark the next PCN-packet. Note that unless the PCN-packets are a large fraction of all the metered-packets then the PCN mechanisms may not work well.
Although the metering functions are described separately from the Marking function, they can be implemented in an integrated fashion.
In some environments encoding states may be scarce, for example MPLS [RFC5129] (Davie, B., Briscoe, B., and J. Tay, “Explicit Congestion Marking in MPLS,” January 2008.), and then it may be preferable to have only two encoding states, as in the baseline encoding [I‑D.ietf‑pcn‑baseline‑encoding] (Moncaster, T., Briscoe, B., and M. Menth, “Baseline Encoding and Transport of Pre-Congestion Information,” September 2009.). In other environments it will be possible to use one of the extension encodings that specify three encoding states.
Section 2.5 states: "if three encoding states are available ... if the threshold meter indicates marking and the excess traffic meter doesn't, then threshold-marking is applied; if the excess traffic meter indicates marking and the threshold traffic meter doesn't, then excess-traffic-marking is applied". The latter case seems infeasible but is possible for a short time - because the meters might react at different speeds when the traffic rate changes.
| TOC |
| Philip Eardley | |
| BT | |
| Adastral Park, Martlesham Heath | |
| Ipswich IP5 3RE | |
| UK | |
| Email: | philip.eardley@bt.com |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.