< draft-ietf-pcn-3-in-1-encoding-00.txt   draft-ietf-pcn-3-in-1-encoding-01.txt >
Congestion and Pre-Congestion B. Briscoe Congestion and Pre-Congestion B. Briscoe
Notification T. Moncaster Notification T. Moncaster
Internet-Draft BT Internet-Draft BT
Intended status: Experimental July 1, 2009 Intended status: Experimental February 10, 2010
Expires: January 2, 2010 Expires: August 14, 2010
PCN 3-State Encoding Extension in a single DSCP PCN 3-State Encoding Extension in a single DSCP
draft-ietf-pcn-3-in-1-encoding-00 draft-ietf-pcn-3-in-1-encoding-01
Abstract
The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain.
The overall rate of the PCN-traffic is metered on every link in the
PCN-domain, and PCN-packets are appropriately marked when certain
configured rates are exceeded. The level of marking allows the
boundary nodes to make decisions about whether to admit or block a
new flow request, and (in abnormal circumstances) whether to
terminate some of the existing flows, thereby protecting the QoS of
previously admitted flows. This document specifies how such marks
are to be encoded into the IP header by re-using the Explicit
Congestion Notification (ECN) codepoints within this controlled
domain. This encoding builds on the baseline encoding and provides
for three PCN encoding states: Not-marked, Threshold-marked and
Excess-traffic-marked.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 2, line 5
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2010. This Internet-Draft will expire on August 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The objective of Pre-Congestion Notification (PCN) is to protect the described in the BSD License.
quality of service (QoS) of inelastic flows within a Diffserv domain.
The overall rate of the PCN-traffic is metered on every link in the
PCN-domain, and PCN-packets are appropriately marked when certain
configured rates are exceeded. The level of marking allows the
boundary nodes to make decisions about whether to admit or block a
new flow request, and (in abnormal circumstances) whether to
terminate some of the existing flows, thereby protecting the QoS of
previously admitted flows. This document specifies how such marks
are to be encoded into the IP header by re-using the Explicit
Congestion Notification (ECN) codepoints within this controlled
domain. This encoding builds on the baseline encoding and provides
for three PCN encoding states: Not-marked, Threshold-marked and
Excess-traffic-marked.
1. Introduction 1. Introduction
The objective of Pre-Congestion Notification (PCN) [RFC5559] is to The objective of Pre-Congestion Notification (PCN) [RFC5559] is to
protect the quality of service (QoS) of inelastic flows within a protect the quality of service (QoS) of inelastic flows within a
Diffserv domain, in a simple, scalable, and robust fashion. Two Diffserv domain, in a simple, scalable, and robust fashion. Two
mechanisms are used: admission control, to decide whether to admit or mechanisms are used: admission control, to decide whether to admit or
block a new flow request, and (in abnormal circumstances) flow block a new flow request, and (in abnormal circumstances) flow
termination to decide whether to terminate some of the existing termination to decide whether to terminate some of the existing
flows. To achieve this, the overall rate of PCN-traffic is metered flows. To achieve this, the overall rate of PCN-traffic is metered
skipping to change at page 2, line 39 skipping to change at page 2, line 43
are below the rate of the link thus providing notification to are below the rate of the link thus providing notification to
boundary nodes about overloads before any congestion occurs (hence boundary nodes about overloads before any congestion occurs (hence
"pre-congestion notification"). "pre-congestion notification").
The level of marking allows boundary nodes to make decisions about The level of marking allows boundary nodes to make decisions about
whether to admit or terminate. This is achieved by marking packets whether to admit or terminate. This is achieved by marking packets
on interior nodes according to some metering function implemented at on interior nodes according to some metering function implemented at
each node. Excess-traffic-marking marks PCN packets that exceed a each node. Excess-traffic-marking marks PCN packets that exceed a
certain reference rate on a link while threshold marking marks all certain reference rate on a link while threshold marking marks all
PCN packets on a link when the PCN traffic rate exceeds a higher PCN packets on a link when the PCN traffic rate exceeds a higher
reference rate [I-D.ietf-pcn-marking-behaviour]. These marks are reference rate [RFC5670]. These marks are monitored by the egress
monitored by the egress nodes of the PCN domain. nodes of the PCN domain.
To fully support these two types of marking, three encoding states To fully support these two types of marking, three encoding states
are needed. The baseline encoding described in are needed. The baseline encoding described in [RFC5696] provides
[I-D.ietf-pcn-baseline-encoding] provides for deployment scenarios for deployment scenarios that only require two PCN encoding states
that only require two PCN encoding states using a single Diffserv using a single Diffserv codepoint. This document describes an
codepoint. This document describes an experimental extension to the experimental extension to the baseline-encoding that adds a third PCN
baseline-encoding that adds a third PCN encoding state in the IP encoding state in the IP header, still using a single Diffserv
header, still using a single Diffserv codepoint. For brevity it will codepoint. For brevity it will be called the 3-in-1 PCN Encoding.
be called the 3-in-1 PCN Encoding.
General PCN-related terminology is defined in the PCN architecture General PCN-related terminology is defined in the PCN architecture
[RFC5559], and terminology specific to packet encoding is defined in [RFC5559], and terminology specific to packet encoding is defined in
the PCN baseline encoding [I-D.ietf-pcn-baseline-encoding]. Note the PCN baseline encoding [RFC5696]. Note that [RFC5696] requires
that [I-D.ietf-pcn-baseline-encoding] requires the PCN Working Group the PCN Working Group to maintain a list of all DSCPs used for PCN
to maintain a list of all DSCPs used for PCN experiments. experiments.
1.1. Changes in This Version (to be removed by RFC Editor) 1.1. Changes in This Version (to be removed by RFC Editor)
From draft-briscoe-pcn-3-in-1-encoding-00: From draft-ietf-pcn-3-in-1-encoding-00 to -01:
* Altered the wording to make sense if
[I-D.ietf-tsvwg-ecn-tunnel] moves to proposed standard.
* References updated
From draft-briscoe-pcn-3-in-1-encoding-00 to
draft-ietf-pcn-3-in-1-encoding-00:
* Filename changed to draft-ietf-pcn-3-in-1-encoding. * Filename changed to draft-ietf-pcn-3-in-1-encoding.
* Introduction altered to include new standard description of * Introduction altered to include new template description of
PCN. PCN.
* References updated. * References updated.
* Terminology brought into line with * Terminology brought into line with [RFC5670].
[I-D.ietf-pcn-marking-behaviour].
* Minor corrections. * Minor corrections.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. The Requirement for Three PCN Encoding States 3. The Requirement for Three PCN Encoding States
The PCN architecture [RFC5559] describes proposed PCN schemes that The PCN architecture [RFC5559] describes proposed PCN schemes that
expect traffic to be metered and marked using both Threshold and expect traffic to be metered and marked using both Threshold and
Excess Traffic schemes. In order to achieve this it is necessary to Excess Traffic schemes. In order to achieve this it is necessary to
allow for three PCN encoding states: one as a Not Marked (NM) state allow for three PCN encoding states: one as a Not Marked (NM) state
and the other two to distinguish these two levels of marking severity and the other two to distinguish these two levels of marking severity
[I-D.ietf-pcn-marking-behaviour]. The way tunnels process the ECN [RFC5670]. The way tunnels processed the ECN field before
field severely limits how to encode these states. [I-D.ietf-tsvwg-ecn-tunnel] severely limited how to encode these
states.
The two bit ECN field seems to offer four possible encoding states, The two bit ECN field seems to offer four possible encoding states,
but one (00) is set aside for traffic controlled by transports that but one (00) is set aside for traffic controlled by transports that
do not understand PCN marking [I-D.ietf-pcn-baseline-encoding], so it do not understand PCN marking [RFC5696], so it would be irregular and
would be irregular and risky to use it as a PCN encoding state. Of risky to use it as a PCN encoding state. Of the three remaining ECN
the three remaining ECN codepoints, only one (11) can be introduced codepoints, only one (11) can be introduced by a congested node
by a congested node within a tunnel and still survive the within a tunnel and still survive the decapsulation behaviour of a
decapsulation behaviour of a tunnel egress as currently standardised. tunnel egress not updated to comply with [I-D.ietf-tsvwg-ecn-tunnel].
The two remaining codepoints are (10) and (01). But if a node within The two remaining codepoints are (10) and (01). But if a node within
the tunnel used either of these two remaining codepoints to try to the tunnel used either of these two remaining codepoints to try to
mark packets with a second severity level, this marking would be mark packets with a second severity level, a tunnel not updated to
removed on decapsulation. The ECN field is constrained to two comply with [I-D.ietf-tsvwg-ecn-tunnel] would remove this marking on
marking states in this way irrespective of whether regular IP in IP decapsulation. The ECN field was constrained to two marking states
tunnelling [RFC3168] or IPsec tunnelling [RFC4301] is used. in this way irrespective of which earlier ECN tunnelling
specification the tunnel complied with, whether regular IP in IP
tunnelling [RFC3168] or IPsec tunnelling [RFC4301].
One way to provide another encoding state that survives tunnelling is One way to provide another encoding state that survives tunnelling is
to use a second Diffserv codepoint [I-D.ietf-pcn-3-state-encoding]. to use a second Diffserv codepoint [I-D.ietf-pcn-3-state-encoding].
Instead, to avoid wasting scarce Diffserv codepoints, we could modify Instead, to avoid wasting scarce Diffserv codepoints, a network
standard tunnels in the PCN region to remove the constraints imposed operator can require tunnels in a PCN region to comply with
by standard tunnelling. [I-D.ietf-tsvwg-ecn-tunnel], thus removing the constraints imposed by
earlier tunnelling specifications.
Therefore this document presupposes tunnels in the PCN region comply Therefore this document presupposes tunnels in the PCN region comply
with the newly proposed decapsulation rules defined in with the newly proposed decapsulation rules defined in
[I-D.ietf-tsvwg-ecn-tunnel]. Then the constraints of standard [I-D.ietf-tsvwg-ecn-tunnel]. Then the constraints of standard
tunnels no longer apply so this document can define a 3-state tunnels no longer apply so this document can define a 3-state
encoding for PCN within one Diffserv codepoint. encoding for PCN within one Diffserv codepoint.
4. The 3-in-1 PCN Encoding 4. The 3-in-1 PCN Encoding
The 3-in-1 PCN Encoding scheme is based closely on that defined in The 3-in-1 PCN Encoding scheme is based closely on the baseline
[I-D.ietf-pcn-baseline-encoding] so that there will be no encoding defined in [RFC5696] so that there will be no compatibility
compatibility issues if a PCN-domain evolves from using the baseline issues if a PCN-domain evolves from using the baseline encoding
encoding scheme to the experimental scheme described here. The exact scheme to the experimental scheme described here. The exact manner
manner in which the PCN encoding states are carried in the IP header in which the PCN encoding states are carried in the IP header is
is shown in Table 1. shown in Figure 1.
Codepoint in ECN field of IP header
<RFC3168 codepoint name>
+--------+--------------+-------------+-------------+---------+ +--------+----------------------------------------------------+
| DSCP | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> | | | Codepoint in ECN field of IP header |
+--------+--------------+-------------+-------------+---------+ | DSCP | <RFC3168 codepoint name> |
| DSCP n | Not-PCN | NM | ThM | ETM | | +--------------+-------------+-------------+---------+
+--------+--------------+-------------+-------------+---------+ | | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
+--------+--------------+-------------+-------------+---------+
| DSCP n | Not-PCN | NM | ThM | ETM |
+--------+--------------+-------------+-------------+---------+
Table 1: 3-in-1 PCN Encoding Figure 1: 3-in-1 PCN Encoding
In Table 1 the 3 PCN states are encoded in the ECN field ([RFC3168]) In Figure 1 the 3 PCN states are encoded in the ECN field [RFC3168]
of an IP packet with its Diffserv field ([RFC2474]) set to DSCP n, of an IP packet with its Diffserv field [RFC2474] set to DSCP n,
which is any PCN-Compatible DiffServ codepoint as defined in Section which is any PCN-Compatible DiffServ codepoint as defined in Section
4.2 of the PCN baseline encoding [I-D.ietf-pcn-baseline-encoding]). 4.2 of the PCN baseline encoding [RFC5696]). The PCN codepoint of a
The PCN codepoint of a packet defines its marking state as follows: packet defines its marking state as follows:
Not-PCN: The packet is controlled by a transport that does not Not-PCN: The packet is controlled by a transport that does not
understand PCN marking, therefore the only valid action to notify understand PCN marking, therefore the only valid action to notify
congestion is to drop the packet; congestion is to drop the packet;
NM: Not marked. A packet in the NM state has not (yet) had its NM: Not marked. A packet in the NM state has not (yet) had its
marking state changed to the ThM or ETM states, but it may be marking state changed to the ThM or ETM states, but it may be
changed to one of these states by a node experiencing congestion changed to one of these states by a node experiencing congestion
or pre-congestion; or pre-congestion;
ThM: Threshold-marked. Such a packet has had its marking state ThM: Threshold-marked. Such a packet has had its marking state
changed by the threshold-meter function changed by the threshold-meter function [RFC5670];
[I-D.ietf-pcn-marking-behaviour];
ETM: Excess-traffic-marked. Such a packet has had its marking state ETM: Excess-traffic-marked. Such a packet has had its marking state
changed by the excess-traffic-meter function changed by the excess-traffic-meter function [RFC5670].
[I-D.ietf-pcn-marking-behaviour].
Packets marked NM, ThM or ETM are termed PCN-packets because their Packets marked NM, ThM or ETM are termed PCN-packets. Their entry
entry into the pcn-domain is controlled by edge nodes that understand into the pcn-domain is controlled by edge nodes that understand how
how to process PCN markings. to process PCN markings [RFC5559].
5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding
To be compliant with the 3-in-1 PCN Encoding, an PCN interior node To be compliant with the 3-in-1 PCN Encoding, an PCN interior node
behaves as follows: behaves as follows:
o Except where explicitly stated otherwise, it MUST comply with o Except where explicitly stated otherwise, it MUST comply with the
[I-D.ietf-pcn-baseline-encoding] basealine encoding specified in [RFC5696]
o It MUST change NM TO ThM if the threshold-meter function indicates o It MUST change NM TO ThM if the threshold-meter function indicates
to mark the packet. to mark the packet.
o It MUST change NM or ThM TO ETM if the excess-traffic-meter o It MUST change NM or ThM TO ETM if the excess-traffic-meter
function indicates to mark the packet. function indicates to mark the packet.
o It MUST NOT change Not-PCN to a PCN-Enabled codepoint and MUST NOT o It MUST NOT change Not-PCN to a PCN-Enabled codepoint and MUST NOT
change a PCN-Enabled codepoint to Not-PCN; change a PCN-Enabled codepoint to Not-PCN;
skipping to change at page 6, line 10 skipping to change at page 6, line 28
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Security Considerations 7. Security Considerations
The security concerns relating to this extended PCN encoding are The security concerns relating to this extended PCN encoding are the
essentially the same as those in [I-D.ietf-pcn-baseline-encoding]. same as those in [RFC5696].
8. Conclusions 8. Conclusions
The 3-in-1 PCN Encoding provides three states to encode PCN markings The 3-in-1 PCN Encoding provides three states to encode PCN markings
in the ECN field of an IP packet using just one Diffserv codepoint. in the ECN field of an IP packet using just one Diffserv codepoint.
One state is for not marked packets while the two others are for PCN One state is for not marked packets while the two others are for PCN
nodes to mark packets with increasing levels of severity. Use of nodes to mark packets with increasing levels of severity. Use of
this encoding presupposes that any tunnels in the PCN region have this encoding presupposes that any tunnels in the PCN region have
been updated to comply with [I-D.ietf-tsvwg-ecn-tunnel]. been updated to comply with [I-D.ietf-tsvwg-ecn-tunnel].
skipping to change at page 6, line 37 skipping to change at page 7, line 11
To be removed by RFC Editor: Comments and questions are encouraged To be removed by RFC Editor: Comments and questions are encouraged
and very welcome. They can be addressed to the IETF Congestion and and very welcome. They can be addressed to the IETF Congestion and
Pre-Congestion working group mailing list <pcn@ietf.org>, and/or to Pre-Congestion working group mailing list <pcn@ietf.org>, and/or to
the authors. the authors.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-pcn-baseline-encoding]
Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information",
draft-ietf-pcn-baseline-encoding-04 (work in progress),
May 2009.
[I-D.ietf-tsvwg-ecn-tunnel] [I-D.ietf-tsvwg-ecn-tunnel]
Briscoe, B., "Tunnelling of Explicit Congestion Briscoe, B., "Tunnelling of Explicit Congestion
Notification", draft-ietf-tsvwg-ecn-tunnel-02 (work in Notification", draft-ietf-tsvwg-ecn-tunnel-03 (work in
progress), March 2009. progress), July 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009. Architecture", RFC 5559, June 2009.
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
Nodes", RFC 5670, November 2009.
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information",
RFC 5696, November 2009.
11.2. Informative References 11.2. Informative References
[I-D.ietf-pcn-3-state-encoding] [I-D.ietf-pcn-3-state-encoding]
Moncaster, T., Briscoe, B., and M. Menth, "A PCN encoding Moncaster, T., Briscoe, B., and M. Menth, "A PCN encoding
using 2 DSCPs to provide 3 or more states", using 2 DSCPs to provide 3 or more states",
draft-ietf-pcn-3-state-encoding-00 (work in progress), draft-ietf-pcn-3-state-encoding-00 (work in progress),
April 2009. April 2009.
[I-D.ietf-pcn-marking-behaviour]
Eardley, P., "Metering and marking behaviour of PCN-
nodes", draft-ietf-pcn-marking-behaviour-04 (work in
progress), June 2009.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
Authors' Addresses Authors' Addresses
Bob Briscoe Bob Briscoe
BT BT
B54/77, Adastral Park B54/77, Adastral Park
Martlesham Heath Martlesham Heath
Ipswich IP5 3RE Ipswich IP5 3RE
 End of changes. 30 change blocks. 
101 lines changed or deleted 107 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/