draft-ietf-pcn-3-in-1-encoding-04.txt   draft-ietf-pcn-3-in-1-encoding-05.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
Intended status: Experimental Moncaster Internet Consulting Intended status: Standards Track Moncaster Internet Consulting
Expires: July 15, 2011 M. Menth Expires: November 22, 2011 M. Menth
University of Tuebingen University of Tuebingen
January 11, 2011 May 21, 2011
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-04 draft-ietf-pcn-3-in-1-encoding-05
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.
On every link in the PCN domain, the overall rate of the PCN-traffic On every link in the PCN domain, the overall rate of the PCN-traffic
is metered, and PCN-packets are appropriately marked when certain is metered, and PCN-packets are appropriately marked when certain
configured rates are exceeded. Egress nodes provide decision points configured rates are exceeded. Egress nodes provide decision points
with information about the PCN-marks of PCN-packets which allows them with information about the PCN-marks of PCN-packets which allows them
to take decisions about whether to admit or block a new flow request, to take decisions about whether to admit or block a new flow request,
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 July 15, 2011. This Internet-Draft will expire on November 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 2, line 35 skipping to change at page 2, line 35
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5 3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5
3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5 3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5
3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6 3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6
3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7 3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7
4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7 4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7
5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8
6.1. Backward Compatibility with Pre-existing PCN 6.1. Backward Compatibility with Pre-existing PCN
Implementations . . . . . . . . . . . . . . . . . . . . . 8 Implementations . . . . . . . . . . . . . . . . . . . . . 9
6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9 6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9
6.2.1. Use of Both Excess-Traffic-Marking and 6.2.1. Use of Both Excess-Traffic-Marking and
Threshold-Marking . . . . . . . . . . . . . . . . . . 9 Threshold-Marking . . . . . . . . . . . . . . . . . . 10
6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 9 6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 10
6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10 6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Co-existence of ECN and PCN (informative) . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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 3, line 49 skipping to change at page 3, line 49
extension to the baseline encoding that uses the EXP codepoint to extension to the baseline encoding that uses the EXP codepoint to
provide a third PCN marking state in the IP header, still using a provide a third PCN marking state in the IP header, still using a
single Diffserv codepoint. This encoding scheme is called "3-in-1 single Diffserv codepoint. This encoding scheme is called "3-in-1
PCN encoding". PCN encoding".
This document only concerns the PCN wire protocol encoding for all IP This document only concerns the PCN wire protocol encoding for all IP
headers, whether IPv4 or IPv6. It makes no changes or headers, whether IPv4 or IPv6. It makes no changes or
recommendations concerning algorithms for congestion marking or recommendations concerning algorithms for congestion marking or
congestion response. Other documents define the PCN wire protocol congestion response. Other documents define the PCN wire protocol
for other header types. For example, the MPLS encoding is defined in for other header types. For example, the MPLS encoding is defined in
[RFC5129]. Appendix A provides an informative example for a mapping [RFC5129] and Appendix A of that document provides an informative
between the encodings in IP and in MPLS. example for a mapping between the encodings in IP and in MPLS.
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-ietf-pcn-3-in-1-encoding-04 to -05:
* Draft moved to standards track as per working group
discussions.
* Added Appendix A discussing ECN handling in the PCN-domain.
* Clarified that this document modifies [RFC5696].
* .......
From draft-ietf-pcn-3-in-1-encoding-03 to -04: From draft-ietf-pcn-3-in-1-encoding-03 to -04:
* Updated document to reflect RFC6040. * Updated document to reflect RFC6040.
* Re-wrote introduction. * Re-wrote introduction.
* Re-wrote section on applicability. * Re-wrote section on applicability.
* Re-wrote section on choosing encoding scheme. * Re-wrote section on choosing encoding scheme.
skipping to change at page 9, line 24 skipping to change at page 9, line 37
6.2. Recommendations for the Use of PCN Encoding Schemes 6.2. Recommendations for the Use of PCN Encoding Schemes
NOTE: This sub-section is informative not normative. NOTE: This sub-section is informative not normative.
When deciding which PCN encoding is suitable an operator needs to When deciding which PCN encoding is suitable an operator needs to
take account of how many PCN states need to be encoded. The take account of how many PCN states need to be encoded. The
following table gives guidelines on which encoding to use with either following table gives guidelines on which encoding to use with either
threshold-marking, excess-traffic marking or both. threshold-marking, excess-traffic marking or both.
+------------------------+--------------------------------+ +------------------------+--------------------------------+
| Used marking schemes | Recommended encoding scheme | | Marking schemes in use | Recommended encoding scheme |
+------------------------+--------------------------------+ +------------------------+--------------------------------+
| Only threshold-marking | Baseline encoding [RFC5696] | | Only threshold-marking | Baseline encoding [RFC5696] |
+------------------------+--------------------------------+ +------------------------+--------------------------------+
| Only excess-traffic- | Baseline encoding [RFC5696] | | Only excess-traffic- | Baseline encoding [RFC5696] |
| marking | or 3-in-1 PCN encoding | | marking | or 3-in-1 PCN encoding |
+------------------------+--------------------------------+ +------------------------+--------------------------------+
| Threshold-marking and | 3-in-1 PCN encoding | | Threshold-marking and | 3-in-1 PCN encoding |
| excess-traffic-marking | | | excess-traffic-marking | |
+------------------------+--------------------------------+ +------------------------+--------------------------------+
skipping to change at page 10, line 48 skipping to change at page 11, line 16
The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field
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.
The use of this PCN encoding scheme presupposes that any tunnels in The use of this PCN encoding scheme presupposes that any tunnels in
the PCN region have been updated to comply with [RFC6040]. the PCN region have been updated to comply with [RFC6040].
10. Acknowledgements 10. Acknowledgements
Thanks to Phil Eardley, Teco Boot, and Kwok Ho Chan for reviewing Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan and Georgios
this document. Karaginannis for reviewing this 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 11, line 29 skipping to change at page 11, line 42
[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.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003.
[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.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008. Marking in MPLS", RFC 5129, January 2008.
[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- [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
Nodes", RFC 5670, November 2009. Nodes", RFC 5670, November 2009.
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information", Encoding and Transport of Pre-Congestion Information",
RFC 5696, November 2009. RFC 5696, November 2009.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, May 2010.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010. Notification", RFC 6040, November 2010.
12.2. Informative References 12.2. Informative References
[I-D.ietf-pcn-cl-edge-behaviour] [I-D.ietf-pcn-cl-edge-behaviour]
Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. Charny, A., Huang, F., Karagiannis, G., Menth, M., and T.
Taylor, "PCN Boundary Node Behaviour for the Controlled Taylor, "PCN Boundary Node Behaviour for the Controlled
Load (CL) Mode of Operation", Load (CL) Mode of Operation",
draft-ietf-pcn-cl-edge-behaviour-08 (work in progress), draft-ietf-pcn-cl-edge-behaviour-08 (work in progress),
December 2010. December 2010.
[I-D.ietf-pcn-encoding-comparison] [I-D.ietf-pcn-encoding-comparison]
Chan, K., Karagiannis, G., Moncaster, T., Menth, M., Karagiannis, G., Chan, K., Moncaster, T., Menth, M.,
Eardley, P., and B. Briscoe, "Pre-Congestion Notification Eardley, P., and B. Briscoe, "Overview of Pre-Congestion
Encoding Comparison", Notification Encoding",
draft-ietf-pcn-encoding-comparison-03 (work in progress), draft-ietf-pcn-encoding-comparison-05 (work in progress),
October 2010. April 2011.
[I-D.ietf-pcn-sm-edge-behaviour] [I-D.ietf-pcn-sm-edge-behaviour]
Charny, A., Karagiannis, G., Menth, M., and T. Taylor, Charny, A., Karagiannis, G., Menth, M., and T. Taylor,
"PCN Boundary Node Behaviour for the Single Marking (SM) "PCN Boundary Node Behaviour for the Single Marking (SM)
Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-05 Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-05
(work in progress), December 2010. (work in progress), December 2010.
Appendix A. Co-existence of ECN and PCN (informative)
The PCN encoding described in this document re-uses the bits of the
ECN field in the IP header. Consequently, this disables ECN within
the PCN domain. Appendix B of [RFC5696] included advice on handling
ECN traffic within a PCN-domain. This appendix clarifies that
advice.
For the purposes of this appendix we define two forms of traffic that
might arrive at a PCN-ingress node. These are Admission-controlled
traffic and Non-admission-controlled traffic.
Admission-controlled traffic will be remarked to the PCN-compatible
DSCP by the PCN-ingress node. Two mechanisms can be used to identify
such traffic:
a. flow signalling associates a filterspec with a need for admission
control (e.g. through RSVP or some equivalent message down from a
SIP server to the ingress), and the PCN-ingress remarks traffic
matching that filterspec to a PCN-compatible DSCP, as its chosen
admission control mechanism.
b. Traffic arrives with a DSCP that implies it requires admission
control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time,
Broadcast TV when used for video on demand, and Multimedia
Conferencing [RFC4594][RFC5865].
All other traffic can be thought of as Non-admission-controlled.
However such traffic may still need to share the same DSCP as the
Admission-controlled traffic. This may be due to policy (for
instance if it is high priority voice traffic), or may be because
there is a shortage of local DSCPs.
ECN [RFC3168] is an end-to-end congestion notification mechanism. As
such it is possible that some traffic entering the PCN-domain may
also be ECN capable The following lists the four cases for how e2e
ECN traffic may wish to be treated while crossing a PCN domain:
ECN capable traffic that does not require admission control and does
not carry a DSCP that the PCN-ingress is using for PCN-capable
traffic. This requires no action.
ECN capable traffic that does not require admission control but
carries a DSCP that the PCN-ingress is using for PCN-capable
traffic. There are two options.
* The ingress maps the DSCP to a local DSCP with the same
scheduling PHB as the original DSCP, and the egress re-maps it
to the original PCN-compatible DSCP.
* The ingress tunnels the traffic, setting not-PCN in the outer
header; note that this turns off ECN for this traffic within
the PCN domain.
The first option is recommended unless the operator is short of
local DSCPs.
ECN-capable Admission-controlled traffic: There are two options.
* The PCN-ingress places this traffic in a tunnel with a PCN-
compatible DSCP in the outer header. The PCN-egress zeroes the
ECN-field before decapsulation.
* The PCN-ingress drops CE-marked packets and the PCN-egress
zeros the ECN field of all PCN packets.
The second option is not recommended unless tunnelling is not
possible for some reason..
ECN-capable Admission-controlled where the e2e transport somehow
indicates that it wants to see PCN marks: NOTE this is currently
experimental only.
Schemes have been suggested where PCN marks may be leaked out of
the PCN-domain and used by the end hosts to modify realtime data
rates. Currently all such schemes are experimental and the
following is for guidance only.
The PCN-ingress needs to tunnel the traffic using [RFC6040]. The
PCN-egress should not zero the ECN field, and the tunnel egress
should use [RFC6040] normal mode (preserving any PCN-marking).
Note that this may turn ECT(0) into ECT(1) and so is not
compatible with the experimental ECN nonce [RFC3540].
In the list above any form of IP-in-IP tunnel can be used unless
specified otherwise. NB, We assume a logical separation of tunneling
and PCN actions in both PCN-ingress and PCN-egress nodes. That is,
any tunneling action happens wholly outside the PCN-domain as
illustrated in the following figure:
, . . . . . PCN-domain . . . . . .
. ,--------. ,--------. .
. _| PCN- |___________________| PCN- |_ .
. / | ingress | | egress | \ .
.| '---------' '--------' |.
| . . . . . . . . . . . . . . .|
,--------. ,--------.
_____| Tunnel | | Tunnel |____
| Ingress | - - ECN preserved inside tunnel - - | Egress |
'---------' '--------'
Figure 4: Separation of tunneling and PCN actions
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
UK UK
Phone: +44 1473 645196 Phone: +44 1473 645196
skipping to change at page 13, line 7 skipping to change at page 16, line 7
Layer Marney Layer Marney
Colchester CO5 9UZ Colchester CO5 9UZ
UK UK
Phone: +44 7764 185416 Phone: +44 7764 185416
Email: toby@moncaster.com Email: toby@moncaster.com
URI: http://www.moncaster.com/ URI: http://www.moncaster.com/
Michael Menth Michael Menth
University of Tuebingen University of Tuebingen
Sand 13 Sand 13
72076 Tuebingen Tuebingen 72076
Germany Germany
Phone: +49 7071 2970505 Phone: +49 7071 2970505
Email: menth@informatik.uni-tuebingen.de Email: menth@informatik.uni-tuebingen.de
 End of changes. 18 change blocks. 
22 lines changed or deleted 149 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/