draft-ietf-pcn-3-in-1-encoding-10.txt   draft-ietf-pcn-3-in-1-encoding-11.txt 
Congestion and Pre-Congestion B. Briscoe Congestion and Pre-Congestion B. Briscoe
Notification BT Notification BT
Internet-Draft T. Moncaster Internet-Draft T. Moncaster
Obsoletes: 5696 (if approved) Moncaster Internet Consulting Obsoletes: 5696 (if approved) Moncaster Internet Consulting
Intended status: Standards Track M. Menth Intended status: Standards Track M. Menth
Expires: September 21, 2012 University of Tuebingen Expires: October 19, 2012 University of Tuebingen
March 20, 2012 April 17, 2012
Encoding 3 PCN-States in the IP header using a single DSCP Encoding 3 PCN-States in the IP header using a single DSCP
draft-ietf-pcn-3-in-1-encoding-10 draft-ietf-pcn-3-in-1-encoding-11
Abstract Abstract
The objective of Pre-Congestion Notification (PCN) is to protect the The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain. 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 The overall rate of the PCN-traffic is metered on every link in the
PCN domain, and PCN-packets are appropriately marked when certain PCN domain, and PCN-packets are appropriately marked when certain
configured rates are exceeded. Egress nodes pass information about configured rates are exceeded. Egress nodes pass information about
these PCN-marks to decision points which then decide whether to admit these PCN-marks to decision points which then decide whether to admit
or block new flow requests or to terminate some already-admitted or block new flow requests or to terminate some already-admitted
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 21, 2012. This Internet-Draft will expire on October 19, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Changes in This Version (to be removed by RFC Editor) . . 5 1.2. Changes in This Version (to be removed by RFC Editor) . . 5
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 8 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 8
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 8 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 9
3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 9 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 9
4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 10 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 10
4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 10 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 10
4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 11 4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 11
4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 11 4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 12
5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 12 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 12
5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 14 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 15
5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 14 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 15
5.2.2. Behaviour of PCN-interior Nodes Using Two 5.2.2. Behaviour of PCN-interior Nodes Using Two
PCN-markings . . . . . . . . . . . . . . . . . . . . . 14 PCN-markings . . . . . . . . . . . . . . . . . . . . . 15
5.2.3. Behaviour of PCN-interior Nodes Using One 5.2.3. Behaviour of PCN-interior Nodes Using One
PCN-marking . . . . . . . . . . . . . . . . . . . . . 15 PCN-marking . . . . . . . . . . . . . . . . . . . . . 16
5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 15 5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 17
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 17
6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 16 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 17
6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 16 6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 18 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 21 Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 22
Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 22 Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 23
Appendix C. Example Mapping between Encoding of PCN-Marks in Appendix C. Example Mapping between Encoding of PCN-Marks in
IP and in MPLS Shim Headers . . . . . . . . . . . . . 24 IP and in MPLS Shim Headers . . . . . . . . . . . . . 26
Appendix D. Rationale for Difference Between the Schemes Appendix D. Rationale for Difference Between the Schemes
using One PCN-Marking . . . . . . . . . . . . . . . . 25 using One PCN-Marking . . . . . . . . . . . . . . . . 27
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 flow termination to terminate some block a new flow request, and flow termination to terminate some
existing flows during serious pre-congestion. To achieve this, the existing flows during serious pre-congestion. To achieve this, the
overall rate of PCN-traffic is metered on every link in the domain, overall rate of PCN-traffic is metered on every link in the domain,
skipping to change at page 5, line 20 skipping to change at page 5, line 20
mapping between IP and MPLS. mapping between IP and MPLS.
1.1. Requirements Language 1.1. 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Changes in This Version (to be removed by RFC Editor) 1.2. Changes in This Version (to be removed by RFC Editor)
From draft-ietf-pcn-3-in-1-encoding-10 to -11:
* Pointed out that any DSCP re-mapping must precede PCN-ingress
processing;
* Ingress behaviour for ECN-capable PCN-packets: allowed any PCN-
capable encapsulation, not just IP-in-IP tunnelling. Added
cautionary note about MPLS PHP;
* PCN-policing at ingress:
+ Clarified what per-flow policing entails;
+ Clarified that a DSCP of zero is '000000';
+ For policed packets, added SHOULD log, MAY alarm;
* Updated refs and acks.
From draft-ietf-pcn-3-in-1-encoding-09 to -10: From draft-ietf-pcn-3-in-1-encoding-09 to -10:
* Added cautionary management advice to S6.2 (backwards * Added cautionary management advice to S6.2 (backwards
compatibility with RFC5696) compatibility with RFC5696)
* Removed "emphatically" from normative "NOT RECOMMENDED" text. * Removed "emphatically" from normative "NOT RECOMMENDED" text.
* Minor editoral changes. * Minor editoral changes.
From draft-ietf-pcn-3-in-1-encoding-08 to -09: From draft-ietf-pcn-3-in-1-encoding-08 to -09:
skipping to change at page 11, line 10 skipping to change at page 11, line 33
[RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking
is configured with a larger reference rate than threshold-marking. is configured with a larger reference rate than threshold-marking.
We take this as a rule and define excess-traffic-marked as a more We take this as a rule and define excess-traffic-marked as a more
severe PCN-mark than Threshold-marked. severe PCN-mark than Threshold-marked.
4.2. Requirements Imposed by Tunnelling 4.2. Requirements Imposed by Tunnelling
[RFC6040] defines rules for the encapsulation and decapsulation of [RFC6040] defines rules for the encapsulation and decapsulation of
ECN markings within IP-in-IP tunnels. The publication of RFC6040 ECN markings within IP-in-IP tunnels. The publication of RFC6040
removed the tunnelling constraints that existed when the encoding of removed the tunnelling constraints that existed when the encoding of
[RFC5696] was written (see section 3.3.2 of [RFC5696] was written (see Section 3.3.2 of
[I-D.ietf-pcn-encoding-comparison]). [I-D.ietf-pcn-encoding-comparison]).
Nonetheless, there is still a problem if there are any legacy (pre- Nonetheless, there is still a problem if there are any legacy (pre-
RFC6040) decapsulating tunnel endpoints within a PCN domain. If a RFC6040) decapsulating tunnel endpoints within a PCN domain. If a
PCN-node Threshold-marks the outer header of a tunnelled packet that PCN-node Threshold-marks the outer header of a tunnelled packet that
has a Not-marked codepoint on the inner header, a legacy decapsulator has a Not-marked codepoint on the inner header, a legacy decapsulator
will forward the packet as Not-marked, losing the Threshold-marking. will forward the packet as Not-marked, losing the Threshold-marking.
The rules on applicability in Section 4.3 below are designed to avoid The rules on applicability in Section 4.3 below are designed to avoid
this problem. this problem.
skipping to change at page 12, line 13 skipping to change at page 12, line 37
present within the PCN domain, the 3-in-1 encoding is not applicable. present within the PCN domain, the 3-in-1 encoding is not applicable.
5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding
Any tunnel endpoint implementation on a PCN-node MUST comply with Any tunnel endpoint implementation on a PCN-node MUST comply with
[RFC6040]. Since PCN is a new capability, this is considered a [RFC6040]. Since PCN is a new capability, this is considered a
reasonable requirement. reasonable requirement.
5.1. PCN-ingress Node Behaviour 5.1. PCN-ingress Node Behaviour
Each ingress link into a PCN domain will apply the four functions If packets arrive from another Diffserv domain, any re-mapping of
described in section 4.2 of [RFC5559] to arriving packets. These Diffserv codepoints MUST happen before PCN-ingress processing.
functions are applied in the following order: classify, police, PCN-
colour, meter. This section describes these four steps, but only the
aspects relevant to packet encoding:
1. Packet classification: The PCN-ingress-node determines whether At each logical ingress link into a PCN domain, each PCN-ingress node
each packet matches the filter spec of an admitted flow. Packets will apply the four functions described in Section 4.2 of [RFC5559]
that match are defined as PCN-packets. to arriving packets. These functions are applied in the following
order: PCN-classify, PCN-police, PCN-colour, PCN-rate-meter. This
section describes these four steps, but only the aspects relevant to
packet encoding:
1. PCN-classification: The PCN-ingress-node determines whether each
packet matches the filter spec of an admitted flow. Packets that
match are defined as PCN-packets.
1b. Extra step if ECN and PCN co-exist: If a packet classified as a 1b. Extra step if ECN and PCN co-exist: If a packet classified as a
PCN-packet arrives with the ECN field already set to a value other PCN-packet arrives with the ECN field already set to a value other
than Not-ECT (i.e. it is from an ECN-capable transport) then to than Not-ECT (i.e. it is from an ECN-capable transport) then to
comply with BCP 124 [RFC4774] it MUST pass through one of the comply with BCP 124 [RFC4774] it MUST pass through one of the
following preparatory steps before the PCN-policing and PCN- following preparatory steps before the PCN-policing and PCN-
colouring steps. The choice between these four actions depends on colouring steps. The choice between these four actions depends on
local policy: local policy:
* Tunnel ECN-capable PCN-packets across the PCN-domain, using an * Encapsulate ECN-capable PCN-packets across the PCN-domain:
RFC6040 tunnel. This tunnelling step MUST precede PCN-policing
and PCN-colouring so that the tunnel is logically outside the
PCN domain (see Appendix B and specifically Figure 2).
This tunnelling policy is the RECOMMENDED choice, and + either within another IP header using an RFC6040 tunnel;
implementations SHOULD use it as the default.
* If tunnelling is not possible, the PCN-ingress-node can allow + or within a lower layer protocol capable of being PCN
through ECN-capable packets without tunnelling, but it MUST marked, such as MPLS (see Appendix C).
drop CE-marked packets at this stage. Failure to drop CE would
risk congestion collapse, because without a tunnel there is no Encapsulation using either of these methods is the RECOMMENDED
mechanism to propagate the CE markings across the PCN-domain policy for ECN-capable PCN-packets, and implementations SHOULD
(see Appendix B). use IP-in-IP tunnelling as the default.
If encapsulation is used, it MUST precede PCN-policing and PCN-
colouring so that the encapsulator and decapsulator are
logically outside the PCN domain (see Appendix B and
specifically Figure 2).
If MPLS encapsulation is used, note that penultimate hop
popping [RFC3031] is incompatible with PCN, unless the
penultimate hop applies the PCN-egress node behaviour before it
pops the PCN-capable MPLS label.
* If some form of encapsulation is not possible, the PCN-ingress-
node can allow through ECN-capable packets without
encapsulation, but it MUST drop CE-marked packets at this
stage. Failure to drop CE would risk congestion collapse,
because without encapsulation there is no mechanism to
propagate the CE markings across the PCN-domain (see
Appendix B).
This policy is NOT RECOMMENDED because there is no tunnel to This policy is NOT RECOMMENDED because there is no tunnel to
protect the e2e ECN capability, which is otherwise disabled protect the e2e ECN capability, which is otherwise disabled
when the PCN-egress-node zeroes the ECN field. when the PCN-egress-node zeroes the ECN field.
* Drop the packet. * Drop the packet.
This policy is also NOT RECOMMENDED, because it precludes the This policy is also NOT RECOMMENDED, because it precludes the
possibility that e2e ECN can co-exist with PCN as a means of possibility that e2e ECN can co-exist with PCN as a means of
controlling congestion. controlling congestion.
* Any other action that complies with [RFC4774] (see Appendix B * Any other action that complies with [RFC4774] (see Appendix B
for an example). for an example).
Appendix B provides more information about the co-existence of PCN Appendix B provides more information about the co-existence of PCN
and ECN. and ECN.
2. PCN-Policing: The PCN-policing function only allows appropriate 2. PCN-Policing: The PCN-policing function only allows appropriate
packets into the PCN behaviour aggregate. Per-flow policing packets into the PCN behaviour aggregate. Per-flow policing
actions may be required, but these are specified in the relevant actions may be required to block rejected flows and to rate-police
edge-behaviour document, e.g. [I-D.ietf-pcn-sm-edge-behaviour], accepted flows, but these are specified in the relevant edge-
behaviour document, e.g. [I-D.ietf-pcn-sm-edge-behaviour],
[I-D.ietf-pcn-cl-edge-behaviour]. [I-D.ietf-pcn-cl-edge-behaviour].
Here we only specify packet-level PCN-policing, which prevents Here we only specify packet-level PCN-policing, which prevents
packets that are not PCN-packets from being forwarded into the packets that are not PCN-packets from being forwarded into the
PCN-domain if PCN-interior-nodes would otherwise mistake them for PCN-domain if PCN-interior-nodes would otherwise mistake them for
PCN-packets. A non-PCN-packet will be confused with a PCN-packet PCN-packets. A non-PCN-packet will be confused with a PCN-packet
if on arrival it meets all three of the following conditions: if on arrival it meets all three of the following conditions:
a) it is not classified as a PCN-packet a) it is not classified as a PCN-packet
skipping to change at page 13, line 44 skipping to change at page 14, line 43
* re-mark the DSCP to a DSCP that is not PCN-compatible; * re-mark the DSCP to a DSCP that is not PCN-compatible;
* tunnel the packet to the PCN-egress with a DSCP in the outer * tunnel the packet to the PCN-egress with a DSCP in the outer
header that is not PCN-compatible; header that is not PCN-compatible;
* drop the packet (NOT RECOMMENDED--see below). * drop the packet (NOT RECOMMENDED--see below).
The choice between these actions depends on local policy. In the The choice between these actions depends on local policy. In the
absence of any operator-specific configuration for this case, by absence of any operator-specific configuration for this case, by
default an implementation SHOULD re-mark the DSCP to zero. default an implementation SHOULD re-mark the DSCP to zero
(000000).
Traffic that meets all three of the above conditions (a-c) is not Whichever policing action is chosen, the PCN-ingress-node SHOULD
PCN-traffic, therefore ideally a PCN-ingress ought not to log the event and MAY also raise an alarm. Alarms SHOULD be rate-
interfere with it, but it has to do something to avoid ambiguous limited so that the anomalous packets will not amplify into a
packet markings. Clearing the ECN field is not an appropriate flood of alarm messages.
policing action, because a network node ought not to interfere
with an e2e signal. Even if such packets seem like an attack, Rationale: Traffic that meets all three of the above conditions
drop would be overkill, because such an attack can be neutralised (a-c) is not PCN-traffic, therefore ideally a PCN-ingress ought
by just re-marking the DSCP. And DSCP re-marking in the network not to interfere with it, but it has to do something to avoid
is legitimate, because the DSCP is not considered an e2e signal. ambiguous packet markings. Clearing the ECN field is not an
appropriate policing action, because a network node ought not to
interfere with an e2e signal. Even if such packets seem like an
attack, drop would be overkill, because such an attack can be
neutralised by just re-marking the DSCP. And DSCP re-marking in
the network is legitimate, because the DSCP is not considered an
e2e signal.
3. PCN-colouring: If a packet has been classified as a PCN-packet, 3. PCN-colouring: If a packet has been classified as a PCN-packet,
once it has been policed, the PCN-ingress-node: once it has been policed, the PCN-ingress-node:
* MUST set a PCN-compatible Diffserv codepoint on all PCN- * MUST set a PCN-compatible Diffserv codepoint on all PCN-
packets. To conserve DSCPs, Diffserv codepoints SHOULD be packets. To conserve DSCPs, Diffserv codepoints SHOULD be
chosen that are already defined for use with admission- chosen that are already defined for use with admission-
controlled traffic. Appendix A gives guidance to implementors controlled traffic. Appendix A gives guidance to implementors
on suitable DSCPs. on suitable DSCPs.
skipping to change at page 18, line 22 skipping to change at page 19, line 29
to encode PCN-marks. One codepoint allows non-PCN traffic to be to encode PCN-marks. One codepoint allows non-PCN traffic to be
carried with the same PCN-compatible DSCP and three other codepoints carried with the same PCN-compatible DSCP and three other codepoints
support three PCN marking states with different levels of severity. support three PCN marking states with different levels of severity.
In general, the use of this PCN encoding scheme presupposes that any In general, the use of this PCN encoding scheme presupposes that any
tunnel endpoints within the PCN-domain comply with [RFC6040]. tunnel endpoints within the PCN-domain comply with [RFC6040].
10. Acknowledgements 10. Acknowledgements
Many thanks to Philip Eardley for providing extensive feedback, Many thanks to Philip Eardley for providing extensive feedback,
criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan, criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan,
Ruediger Geib, Georgios Karagiannis, Adrian Farrel and everyone else Ruediger Geib, Georgios Karagiannis, James Polk, Tom Taylor, Adrian
who has commented on the document. Farrel and everyone else who has commented on the document.
11. Comments Solicited 11. Comments Solicited
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.
12. References 12. References
skipping to change at page 19, line 26 skipping to change at page 20, line 33
Notification", RFC 6040, Notification", RFC 6040,
November 2010. November 2010.
12.2. Informative References 12.2. Informative References
[I-D.ietf-pcn-cl-edge-behaviour] Charny, A., Huang, F., [I-D.ietf-pcn-cl-edge-behaviour] Charny, A., Huang, F.,
Karagiannis, G., Menth, M., and Karagiannis, G., Menth, M., and
T. Taylor, "PCN Boundary Node T. Taylor, "PCN Boundary Node
Behaviour for the Controlled Load Behaviour for the Controlled Load
(CL) Mode of Operation", draft- (CL) Mode of Operation", draft-
ietf-pcn-cl-edge-behaviour-12 ietf-pcn-cl-edge-behaviour-14
(work in progress), (work in progress), April 2012.
February 2012.
[I-D.ietf-pcn-encoding-comparison] Karagiannis, G., Chan, K., [I-D.ietf-pcn-encoding-comparison] Karagiannis, G., Chan, K.,
Moncaster, T., Menth, M., Moncaster, T., Menth, M.,
Eardley, P., and B. Briscoe, Eardley, P., and B. Briscoe,
"Overview of Pre-Congestion "Overview of Pre-Congestion
Notification Encoding", draft- Notification Encoding", draft-
ietf-pcn-encoding-comparison-09 ietf-pcn-encoding-comparison-09
(work in progress), March 2012. (work in progress), March 2012.
[I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., [I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G.,
Menth, M., and T. Taylor, "PCN Menth, M., and T. Taylor, "PCN
Boundary Node Behaviour for the Boundary Node Behaviour for the
Single Marking (SM) Mode of Single Marking (SM) Mode of
Operation", draft-ietf-pcn-sm- Operation", draft-ietf-pcn-sm-
edge-behaviour-09 (work in edge-behaviour-12 (work in
progress), February 2012. progress), April 2012.
[RFC2597] Heinanen, J., Baker, F., Weiss, [RFC2597] Heinanen, J., Baker, F., Weiss,
W., and J. Wroclawski, "Assured W., and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, Forwarding PHB Group", RFC 2597,
June 1999. June 1999.
[RFC3031] Rosen, E., Viswanathan, A., and
R. Callon, "Multiprotocol Label
Switching Architecture",
RFC 3031, January 2001.
[RFC3246] Davie, B., Charny, A., Bennet, [RFC3246] Davie, B., Charny, A., Bennet,
J., Benson, K., Le Boudec, J., J., Benson, K., Le Boudec, J.,
Courtney, W., Davari, S., Firoiu, Courtney, W., Davari, S., Firoiu,
V., and D. Stiliadis, "An V., and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002. Behavior)", RFC 3246, March 2002.
[RFC3540] Spring, N., Wetherall, D., and D. [RFC3540] Spring, N., Wetherall, D., and D.
Ely, "Robust Explicit Congestion Ely, "Robust Explicit Congestion
Notification (ECN) Signaling with Notification (ECN) Signaling with
 End of changes. 24 change blocks. 
66 lines changed or deleted 115 lines changed or added

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