wdiff draft-ietf-pcn-3-in-1-encoding-02.txt draft-ietf-pcn-3-in-1-encoding-03.txt

Congestion and Pre-Congestion B. Briscoe
Notification BT
Internet-Draft T. Moncaster
Internet-Draft BT
Intended status: Experimental March 08, 2010 Independent
Expires: September 9, January 13, 2011 M. Menth
University of Wuerzburg
July 12, 2010

PCN 3-State

Encoding Extension 3 PCN-States in the IP header using a single DSCP
draft-ietf-pcn-3-in-1-encoding-02
draft-ietf-pcn-3-in-1-encoding-03

Abstract

The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain.
The
On every link in the PCN domain, the overall rate of the PCN-traffic
is metered on every link in the
PCN-domain, metered, and PCN-packets are appropriately marked when certain
configured rates are exceeded. The level Egress nodes provide decision points
with information about the PCN-marks of marking PCN-packets which allows the
boundary nodes them
to make take 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 already admitted flows. flows during serious pre-
congestion.

This document specifies how such marks PCN-marks are to be encoded into the IP
header by re-using the Explicit Congestion Notification (ECN)
codepoints within this controlled
domain. a PCN-domain. This encoding builds on the baseline
encoding of RFC5696 and provides for three different PCN encoding states: Not-marked, Threshold-marked and
Excess-traffic-marked. marking
states using a single DSCP: not-marked (NM), threshold-marked (ThM)
and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN
encoding.

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. (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts.
Drafts is at http://datatracker.ietf.org/drafts/current/.

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. January 13, 2011.

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 Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes in This Version (to be removed by RFC Editor) . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5
3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5
3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6
3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 6
4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7
5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8
6.1. Backward Compatibility with Pre-existing PCN
Implementations . . . . . . . . . . . . . . . . . . . . . 8
6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9
6.2.1. Use of Both Excess-Traffic-Marking and
Threshold-Marking . . . . . . . . . . . . . . . . . . 9
6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 9
6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

1. Introduction

The objective of Pre-Congestion Notification (PCN) [RFC5559] is to
protect 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, to decide whether to admit or
block a new flow request, and (in abnormal circumstances) flow termination to decide whether to
terminate some of the existing
flows. already admitted flows during serious pre-congestion.
To achieve this, 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 "pre-
congestion notification").

The level of

Two metering and marking allows boundary nodes to make decisions about
whether to admit or terminate. This is achieved by functions are proposed in [RFC5670] that are
configured with reference rates. Threshold- marking packets
on interior nodes according to some metering function implemented at
each node. Threshold-traffic-marking marks all PCN
packets once they
exceed the threshold-traffic-rate their traffic rate on a link while Excess-traffic-
marking exceeds the configured
reference rate (PCN-threshold-rate). Excess-traffic-marking marks
only those PCN packets that exceed the excess-traffic-
rate, which is higher than the threshold-traffic-rate [RFC5670].
These marks are monitored by configured reference rate
(PCN-excess-rate). The PCN-excess-rate is typically larger than the egress
PCN-threshold-rate [RFC5559]. Egress nodes of monitor the PCN domain.

To fully support these two types PCN-marks of marking, three encoding states
are needed.
received PCN-packets and provide information about the PCN-marks to
decision points which take decisions about flow admission and
termination on this basis [I-D.ietf-pcn-cl-edge-behaviour],
[I-D.ietf-pcn-sm-edge-behaviour].

The baseline encoding described defined in [RFC5696] provides
for deployment scenarios that only require describes how two PCN encoding
marking states can be encoded using a single Diffserv codepoint.
However, to support the application of two different marking
algorithms in a PCN-domain, for example as required in
[I-D.ietf-pcn-cl-edge-behaviour], three PCN marking states are
needed. This document describes an
experimental extension to the baseline-encoding baseline
encoding that adds a third PCN
encoding marking state in the IP header, still
using a single Diffserv codepoint. For brevity it will be This encoding scheme is called the 3-in-1
ao&#731;3-in-1 PCN Encoding.

General PCN-related terminology is defined in the encodingao&#711;.

All PCN architecture
[RFC5559], and terminology specific to packet encoding is defined in
the schemes require an additional marking state to
indicate non-PCN traffic. Therefore, four codepoints are required to
encode three PCN baseline encoding [RFC5696]. Note that [RFC5696] requires marking states.

This document only concerns the PCN Working Group to maintain a list of wire protocol encoding for all DSCPs used IP
headers, whether IPv4 or IPv6. It makes no changes or
recommendations concerning algorithms for congestion marking or
congestion response. Other documents define the PCN
experiments. wire protocol
for other header types. For example, the MPLS encoding is defined in
[RFC5129]. Appendix A provides an informative example for a mapping
between the encodings in IP and in MPLS.

1.1. Changes in This Version (to be removed by RFC Editor)

From draft-ietf-pcn-3-in-1-encoding-02 to -03:

* Corrected mistakes in introduction and improved overall
readability.

* Added new terminology.

* Rewrote a good part of Section 4 and 5 to achieve more clarity.

* Added appendix explaining when to use which encoding scheme and
how to encode them in MPLS shim headers.

* Added new co-author.

From draft-ietf-pcn-3-in-1-encoding-01 to -02:

* Corrected mistake in introduction, which wrongly stated that
the threshold-traffic rate is higher than the excess-traffic
rate. Other minor corrections.

* Updated acks & refs.

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.

* Introduction altered to include new template description of
PCN.

* References updated.

* Terminology brought into line with [RFC5670].

* Minor corrections.

2. 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.1. Terminology

General PCN-related terminology is defined in the PCN architecture
[RFC5559], and terminology specific to packet encoding is defined in
the PCN baseline encoding [RFC5696]. Additional terminology is
defined below.

PCN encoding: mapping of PCN marking states to specific codepoints
in the packet header.

3. The Requirement Requirements for Three and Applicability of 3-in-1 PCN Encoding States

3.1. PCN Requirements

The PCN architecture [RFC5559] describes proposed PCN schemes defines that
expect traffic to be metered and marked using both Threshold and
Excess Traffic schemes. In order PCN-ingress-nodes of a
PCN-domain control incoming packets. Packets belonging to achieve this it is necessary PCN-
controlled flows are subject to
allow for three PCN encoding states: one as a Not Marked (NM) state metering and marking, they are
termed PCN-packets, and PCN-ingress-nodes mark them as not-marked
(PCN-colouring). Any node in the other two to distinguish these PCN-domain may perform PCN metering
and marking and mark PCN-packets if needed. There are two levels of different
metering and marking schemes: threshold-marking and excess-traffic-
marking severity [RFC5670]. The way tunnels processed Some edge behaviors require only a single marking
scheme [I-D.ietf-pcn-sm-edge-behaviour], others require both
[I-D.ietf-pcn-cl-edge-behaviour]. In the ECN field before
[I-D.ietf-tsvwg-ecn-tunnel] severely limited how latter case, three PCN
marking states are needed: not-marked (NM) to encode these
states.

The two bit ECN field seems indicate not-marked
packets, threshold-marked (ThM) to offer four possible encoding states,
but one (00) is set aside for traffic controlled indicate packets marked by transports that
do not understand PCN marking [RFC5696], so it would be irregular the
threshold-marker, and
risky excess-traffic-marked (ETM) to use it as a PCN encoding state. Of indicate packets
marked by the three remaining ECN
codepoints, only excess-traffic-marker [RFC5670]. As threshold-marking
and excess-traffic-marking start marking packets at different load
conditions, one (11) can be introduced by marking scheme indicates more severe pre-congestion
than the other in terms of higher load. If a congested node
within packet has been marked
by both a tunnel threshold-marker and still survive an excess-traffic-marker, it is marked
with the decapsulation behaviour of more severe state. Therefore, a
tunnel egress fourth PCN marking state
indicating that a packet is marked by both markers is not updated needed.

Nonetheless, in addition to comply with [I-D.ietf-tsvwg-ecn-tunnel].
The two remaining codepoints are (10) and (01). But if a node within for the tunnel used either of these two remaining codepoints to try three PCN marking
states a fourth codepoint is required to
mark indicate packets with a second severity level, a tunnel that are
not updated to
comply with [I-D.ietf-tsvwg-ecn-tunnel] would remove this marking on
decapsulation. The ECN field was constrained to PCN-capable (termed the not-PCN codepoint).

In all current PCN edge behaviors that use two marking states
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 schemes
[RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking
is
to use a second Diffserv codepoint [I-D.ietf-pcn-3-state-encoding].
Instead, to avoid wasting scarce Diffserv codepoints, a network
operator can require tunnels in a PCN region to comply with
[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 configured with the newly proposed decapsulation rules defined in
[I-D.ietf-tsvwg-ecn-tunnel]. Then the constraints of standard
tunnels no longer apply so a larger reference rate than threshold-marking.
We take this document can as a rule and define excess-traffic-marked as a 3-state
encoding for PCN within one Diffserv codepoint.

4. The 3-in-1 PCN more
severe PCN-mark than threshold-marked.

3.2. Requirements Imposed by Baseline Encoding

The 3-in-1 PCN Encoding scheme is based closely on the baseline encoding defined in scheme [RFC5696] was defined so that there will it could
be no compatibility
issues if a PCN-domain evolves from using the baseline encoding
scheme extended to accommodate an additional marking state. It provides
rules to embed the experimental scheme described here. The exact manner
in which the PCN encoding of two PCN states are carried in the IP header is
shown in header.
Figure 1.
+--------+----------------------------------------------------+
| | Codepoint in ECN field 1 shows the structure of IP header |
| DSCP | <RFC3168 the former type-of-service field. It
contains the 6-bit Differentiated Services (DS) field that holds the
DS codepoint name> |
| +--------------+-------------+-------------+---------+
| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
+--------+--------------+-------------+-------------+---------+
| DSCP n | Not-PCN | NM (DSCP) [RFC2474] and the 2-bit ECN field [RFC3168].
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| ThM DS FIELD | ETM ECN FIELD |
+--------+--------------+-------------+-------------+---------+
+-----+-----+-----+-----+-----+-----+-----+-----+

Figure 1: 3-in-1 PCN Encoding

In Figure 1 the 3 PCN states are encoded in Structure of the ECN former type-of-service field [RFC3168]
of an in IP packet with its Diffserv field [RFC2474]

Baseline encoding defines that the DSCP must be set to a PCN-
compatible DSCP n,
which is any PCN-Compatible DiffServ codepoint as defined in Section
4.2 of n and the PCN baseline ECN-field [RFC3168] indicates the specific
PCN-mark. Baseline encoding [RFC5696]). The PCN codepoint of a
packet defines its marking state as follows:

Not-PCN: The packet is controlled by offers four possible encoding states
within a transport that does not
understand PCN marking, therefore single DSCP with the only valid action to notify
congestion following restrictions.

o Codepoint `00' (not-ECT) is used to drop the packet;

NM: Not marked. A packet in indicate non-PCN traffic as
"not-PCN". This allows the NM state has not (yet) had its
marking state changed use of a DSCP for both PCN and non-PCN
traffic.

o Codepoint `10' (ECT(0)) is used to indicate Not-marked PCN
traffic.

o Codepoint `11' (CE) is used to indicate the ThM or ETM states, but it most severe PCN-mark.

o Codepoint `01' (ECT(1)) is available for experimental use and may
be
changed to one of these states by a node experiencing congestion
or pre-congestion;

ThM: Threshold-marked. Such a packet has had its marking state
changed re-used by other PCN encodings such as the threshold-meter function [RFC5670];

ETM: Excess-traffic-marked. Such presently defined
3-in-1 PCN encoding.

3.3. Applicability of 3-in-1 PCN Encoding

When PCN traffic is tunneled IP-in-IP within a packet has had its marking state
changed PCN-domain, PCN-marks
must be preserved in all outer IP headers after encapsulation and
decapsulation. This property is violated by legacy encapsulation and
decapsulation rules [RFC3168], [RFC4301] due to the excess-traffic-meter function [RFC5670].

Packets marked NM, ThM or ETM are termed PCN-packets. Their entry
into way they treat
the pcn-domain is controlled by edge nodes that understand how ECN field. This led to process PCN markings [RFC5559].

5. Behaviour strong limitations regarding how PCN-
marks can be encoded using the ECN field of a PCN Node Compliant the IP header
[I-D.ietf-pcn-encoding-comparison]. Therefore, baseline encoding
[RFC5696] was defined which works well with legacy tunnels but
supports only two PCN marking states.

Since then, new rules have been defined for IP-in-IP tunneling
[I-D.ietf-tsvwg-ecn-tunnel] so that the present 3-in-1 PCN Encoding

To be compliant with encoding
has more freedom to accommodate PCN-marks using the ECN field. From
this follows that 3-in-1 PCN Encoding, an PCN interior node
behaves as follows:

o Except where explicitly stated otherwise, it MUST encoding may be applied only in PCN-
domains that comply with [I-D.ietf-tsvwg-ecn-tunnel] or do not use
tunneling.

4. Definition of 3-in-1 PCN Encoding

The 3-in-1 PCN encoding scheme is an extension of the baseline
encoding specified scheme defined in [RFC5696] [RFC5696]. The PCN requirements and the
extension rules for baseline encoding presented in the previous
section determine how PCN encoding states are carried in the IP
headers. This is shown in Figure 2.
+--------+----------------------------------------------------+
| | Codepoint in ECN field of IP header |
| DSCP | <RFC3168 codepoint name> |
| +--------------+-------------+-------------+---------+
| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
+--------+--------------+-------------+-------------+---------+
| DSCP n | Not-PCN | NM | ThM | ETM |
+--------+--------------+-------------+-------------+---------+

Figure 2: 3-in-1 PCN Encoding

Like baseline encoding, 3-in-1 PCN encoding also uses a PCN
compatible DSCP n and the ECN field for the encoding of PCN-marks.
The PCN-marks have the following meaning.

Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not
subject to PCN metering and marking.

NM: Not-marked. Indicates a PCN-packet that has not yet been marked
by any PCN marker.

ThM: Threshold-marked. Indicates a PCN-packet that has been marked
by a threshold-marker [RFC5670].

ETM: Excess-traffic-marked. Indicates a PCN-packet that has been
marked by an excess-traffic-marker [RFC5670].

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
behaves as follows:

o It MUST change NM to ThM if the threshold-meter function indicates
to mark the packet.

o It MUST change NM or ThM to ETM if the excess-traffic-meter
function indicates to mark the packet.

o It MUST NOT change Not-PCN not-PCN to a PCN-Enabled codepoint NM, ThM, or ETM, and MUST NOT change
a PCN-Enabled codepoint NM, ThM, or ETM to Not-PCN; not-PCN;

o It MUST NOT change ThM to NM;

o It MUST NOT change ETM to ThM or to NM;

In other words, a PCN interior node MUST NOT mark PCN-packets into
non-PCN packets and vice-versa, and it may increase the severity of
packet marking
the PCN-mark of a PCN-packet, but it MUST NOT decrease it, where it.

6. Backward Compatibility

Discussion of backward compatibility between PCN encoding schemes and
previous uses of the ECN field is given in Section 6 of [RFC5696].

6.1. Backward Compatibility with Pre-existing PCN Implementations

This encoding complies with the rules for extending the baseline PCN
encoding schemes in Section 5 of [RFC5696].

The term "compatibility" is meant in the following sense. It is
possible to operate nodes with baseline encoding [RFC5696] and 3-in-1
encoding in the same PCN domain. The nodes with baseline encoding
MUST perform excess-traffic-marking because the 11 codepoint of
3-in-1 encoding also means excess-traffic-marked. PCN-boundary-nodes
of such domains are required to interpret the full 3-in-1 encoding
and not just baseline encoding, otherwise they cannot interpret the
01 codepoint.

Using nodes that perform only excess-traffic-marking may make sense
in networks using the CL edge behavior
[I-D.ietf-pcn-cl-edge-behaviour]. Such nodes are able to notify the
egress only about severe pre-congestion when traffic needs to be
terminated. This seems reasonable for locations that are not
expected to see any pre-congestion, but excess-traffic-marking gives
them a means to terminate traffic if unexpected overload still
occurs.

6.2. Recommendations for the Use of PCN Encoding Schemes

Figure 3: Use of PCN encoding schemes

Figure 3 gives guidelines under which conditions baseline encoding
and 3-in-1 PCN encoding would typically be used.

6.2.1. Use of Both Excess-Traffic-Marking and Threshold-Marking

If both excess-traffic-marking and threshold-marking are enabled in a
PCN-domain, 3-in-1 encoding should be used as described in this
document.

6.2.2. Unique Use of Excess-Traffic-Marking

If only excess-traffic-marking is enabled in a PCN-domain, baseline
encoding or 3-in-1 encoding may be used. They lead to the same
encoding because PCN-boundary nodes will interpret baseline "PCN-
marked (PM)" as "excess-traffic-marked (ETM)".

6.2.3. Unique Use of Threshold-Marking

No scheme is currently proposed to solely use threshold-marking.
However, if only threshold-marking is enabled in a PCN-domain,
baseline encoding SHOULD be used. This is because threshold marking
will work in combination with legacy tunnel decapsulators within the
PCN-domain, while using threshold marking with the 3-in-1 encoding
requires that tunnel decapsulators within a PCN-domain comply with
[I-D.ietf-tsvwg-ecn-tunnel].

7. IANA Considerations

This memo includes no request to IANA.

Note to RFC Editor: this section may be removed on publication as an
RFC.

8. Security Considerations

The security concerns relating to this extended PCN encoding are the
same as those in [RFC5696]. In summary, PCN-boundary nodes are
responsible for ensuring inappropriate PCN markings do not leak into
or out of a PCN domain, and the current phase of the PCN architecture
assumes that all the nodes of a PCN-domain are entirely under the
control of a single operator, or a set of operators who trust each
other.

Given the only difference between the baseline encoding and the
present 3-in-1 encoding is the order use of
severity increases from NM through ThM to ETM.

6. IANA Considerations

This memo includes the 01 codepoint, no request to IANA.

Note to RFC Editor: this section may be removed on publication as an
RFC.

7. Security Considerations

The new
security concerns relating to this extended PCN encoding issues are the
same raised, as those this codepoint was already available
for experimental use in [RFC5696].

8. the baseline encoding.

9. Conclusions

The 3-in-1 PCN Encoding provides three states to encode PCN markings
in encoding uses a PCN-compatible DSCP and the ECN field of an IP packet using just one Diffserv codepoint.
to encode PCN-marks. One state is for not marked packets while codepoint allows non-PCN traffic to be
carried with the two others are for same PCN-compatible DSCP and three other codepoints
support three PCN
nodes to mark packets marking states with increasing different levels of severity. Use
The use of this PCN encoding scheme presupposes that any tunnels in
the PCN region have been updated to comply with
[I-D.ietf-tsvwg-ecn-tunnel].

10. Acknowledgements

Thanks to Phil Eardley, Teco Boot, and Kwok Ho Chan and Michael Menth for reviewing this.

10.
this document.

11. Comments Solicited

To be removed by RFC Editor: Comments and questions are encouraged
and very welcome. They can be addressed to the IETF Congestion and
Pre-Congestion working group mailing list <pcn@ietf.org>, and/or to
the authors.

11.

12. References

11.1.
12.1. Normative References

[I-D.ietf-tsvwg-ecn-tunnel]
Briscoe, B., "Tunnelling of Explicit Congestion
Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in
progress), March 2010.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.

[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008.

[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
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.

12.2. Informative References

[I-D.ietf-pcn-3-state-encoding]
Briscoe, B.,

[I-D.ietf-pcn-cl-edge-behaviour]
Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
Taylor, "PCN Boundary Node Behaviour for the Controlled
Load (CL) Mode of Operation",
draft-ietf-pcn-cl-edge-behaviour-06 (work in progress),
June 2010.

[I-D.ietf-pcn-encoding-comparison]
Chan, K., Karagiannis, G., Moncaster, T., and M. Menth, "A PCN encoding
using 2 DSCPs to provide 3 or more states",
draft-ietf-pcn-3-state-encoding-01 M.,
Eardley, P., and B. Briscoe, "Pre-Congestion Notification
Encoding Comparison",
draft-ietf-pcn-encoding-comparison-02 (work in progress),
February
March 2010.

[RFC4301] Kent, S.

[I-D.ietf-pcn-sm-edge-behaviour]
Charny, A., Karagiannis, G., Menth, M., and K. Seo, "Security Architecture T. Taylor,
"PCN Boundary Node Behaviour for the
Internet Protocol", RFC 4301, December 2005. Single Marking (SM)
Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-03
(work in progress), June 2010.

[I-D.ietf-tsvwg-ecn-tunnel]
Briscoe, B., "Tunnelling of Explicit Congestion
Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in
progress), March 2010.

Authors' Addresses

Bob Briscoe
BT
B54/77, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK

Phone: +44 1473 645196
Email: bob.briscoe@bt.com
URI: http://bobbriscoe.net/

Toby Moncaster
BT
c/o B54/70, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK
Independent

Email: toby@moncaster.com

Michael Menth
University of Wuerzburg
room B206, Institute of Computer Science
Am Hubland
Wuerzburg 97074
Germany

Phone: +44 1206 332805 +49 931 31 86644
Email: toby.moncaster@bt.com menth@informatik.uni-wuerzburg.de