draft-ietf-pcn-psdm-encoding-01.txt   draft-ietf-pcn-psdm-encoding-02.txt 
Congestion and Pre Congestion M. Menth Congestion and Pre Congestion M. Menth
Internet-Draft University of Wuerzburg Internet-Draft University of Tuebingen
Intended status: Experimental J. Babiarz Intended status: Historic J. Babiarz
Expires: September 6, 2010 Nortel Networks Expires: September 13, 2012 3inova Networks Inc
T. Moncaster T. Moncaster
BT University of Cambridge
B. Briscoe B. Briscoe
BT & UCL BT
March 5, 2010 March 12, 2012
PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding) PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding)
draft-ietf-pcn-psdm-encoding-01 draft-ietf-pcn-psdm-encoding-02
Abstract Abstract
Pre-congestion notification (PCN) is a link-specific and load- Pre-congestion notification (PCN) is a link-specific and load-
dependent packet re-marking mechanism and provides in Differentiated dependent packet re-marking mechanism and provides in Differentiated
Services networks feedback to egress nodes about load conditions Services networks feedback to egress nodes about load conditions
within the domain. It is used to support admission control and flow within the domain. It is used to support admission control and flow
termination decision in a simple way. This document proposes how PCN termination decision in a simple way. This document proposes how PCN
marks can be encoded into the IP header for packet-specific dual marks can be encoded into the IP header for packet-specific dual
marking (PSDM). PSDM encoding provides three different codepoints: marking (PSDM). PSDM encoding provides three different codepoints:
not-ETM, not-ThM, and PM. Excess-traffic-marking may re-mark not- not-ETM, not-ThM, and PM. Excess-traffic-marking may re-mark not-
ETM-packets to PM and threshold-marking may re-mark not-ThM-packets ETM-packets to PM and threshold-marking may re-mark not-ThM-packets
to PM. to PM.
Status Status
This memo is posted as an Internet-Draft with an intent to eventually Since its original publication, the baseline encoding (RFC5696) on
be published as an experimental RFC. which this document depends has become obsolete. The PCN working
GRoup has chosen to publish this as a historical document to preserve
the details of the encoding and to allow it to be cited in other
documents.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- 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 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on September 13, 2012.
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 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Encoding for Packet-Specific Dual Marking . . . . . . . . . . 6 3. Encoding for Packet-Specific Dual Marking . . . . . . . . . . 6
3.1. Proposed Encoding and Expected Node Behavior . . . . . . . 6 3.1. Proposed Encoding and Expected Node Behavior . . . . . . . 6
3.1.1. PCN Codepoints . . . . . . . . . . . . . . . . . . . . 6 3.1.1. PCN Codepoints . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Codepoint Handling by PCN Ingress Nodes . . . . . . . 6 3.1.2. Codepoint Handling by PCN Ingress Nodes . . . . . . . 6
3.1.3. Codepoint Handling by PCN Interfaces . . . . . . . . . 6 3.1.3. Codepoint Handling by PCN Interfaces . . . . . . . . . 7
3.1.4. Codepoint Handling by PCN Egress Nodes . . . . . . . . 7 3.1.4. Codepoint Handling by PCN Egress Nodes . . . . . . . . 7
3.2. Reasons for the Proposed Encoding . . . . . . . . . . . . 7 3.2. Reasons for the Proposed Encoding . . . . . . . . . . . . 7
3.2.1. Scarcity of DSCPs . . . . . . . . . . . . . . . . . . 7 3.2.1. Scarcity of DSCPs . . . . . . . . . . . . . . . . . . 7
3.2.2. Problems with Tunneling . . . . . . . . . . . . . . . 7 3.2.2. Problems with Tunneling . . . . . . . . . . . . . . . 7
3.2.3. Problems with the ECN Field . . . . . . . . . . . . . 8 3.2.3. Problems with the ECN Field . . . . . . . . . . . . . 8
3.3. Handling of ECN Traffic . . . . . . . . . . . . . . . . . 8 3.3. Handling of ECN Traffic . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 9 7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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 (AC), to decide whether to mechanisms are used: admission control (AC), to decide whether to
admit or block a new flow request, and (in abnormal circumstances) admit or block a new flow request, and (in abnormal circumstances)
flow termination (FT) to decide whether to terminate some of the flow termination (FT) to decide whether to terminate some of the
existing flows. To achieve this, the overall rate of PCN-traffic is existing flows. To achieve this, the overall rate of PCN-traffic is
skipping to change at page 5, line 12 skipping to change at page 5, line 12
admissible-rate) and FT based on excess-traffic-marking (reference admissible-rate) and FT based on excess-traffic-marking (reference
rate = PCN-supportable-rate)[Menth09f]. rate = PCN-supportable-rate)[Menth09f].
The motivation for PSDM encoding is that probe packets are subject The motivation for PSDM encoding is that probe packets are subject
only to threshold-marking and that data packets are subject only to only to threshold-marking and that data packets are subject only to
excess-traffic-marking. Nevertheless, routers should not need to excess-traffic-marking. Nevertheless, routers should not need to
differentiate explicitly between probe and data packets since packets differentiate explicitly between probe and data packets since packets
are a priori marked with an appropriate codepoint (not-ETM, not-ThM) are a priori marked with an appropriate codepoint (not-ETM, not-ThM)
indicating the marking mechanism applying to them. indicating the marking mechanism applying to them.
Following the publication of new rules relating to the tunnelling of
ECN marks [RFC6040], the PCN workign group decided to obsolete
[RFC5696] in favour of the 3-in-1 encoding
[I-D.ietf-pcn-3-in-1-encoding]. A side-effect of this decision was
to make the PSDM encoding obsolete. However the PCN working group
feels it is useful to have a formal historical record of this
encoding. This ensures details of the encoding are not lost and also
allows it to be cited in other documents.
1.1. Requirements notation 1.1. Requirements notation
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].
2. Terminology 2. Terminology
Most of the terminology used in this document is defined in Most of the terminology used in this document is defined in
[RFC5559]. The following additional terms are defined in this [RFC5559]. The following additional terms are defined in this
skipping to change at page 8, line 49 skipping to change at page 9, line 12
is enforced when PCN packets leave the PCN domain. As a consequence, is enforced when PCN packets leave the PCN domain. As a consequence,
all CE-marked PCN packets must be dropped before entering a PCN all CE-marked PCN packets must be dropped before entering a PCN
domain and the ECN field of all PCN packets must be reset to not-ECT domain and the ECN field of all PCN packets must be reset to not-ECT
when leaving a PCN domain. when leaving a PCN domain.
3.3. Handling of ECN Traffic 3.3. Handling of ECN Traffic
ECN is intended to control elastic traffic as TCP reacts to ECN ECN is intended to control elastic traffic as TCP reacts to ECN
marks. Inelastic real-time traffic is mostly not transmitted over marks. Inelastic real-time traffic is mostly not transmitted over
TCP such that this application of ECN is not appropriate. However, TCP such that this application of ECN is not appropriate. However,
there are plans to reuse ECN signals for rate adaptation there have been proposals made that would re-use the PCN signals for
[ecn-pcn-usecases]. Therefore, two different options might be rate adaptation. Therefore, two different options might be useful.
useful.
o preserve ECN marks from outside a PCN domain, i.e. CE-marked o preserve ECN marks from outside a PCN domain, i.e. CE-marked
packets should not be dropped. To handle this case, ECN packets packets should not be dropped. To handle this case, ECN packets
should be tunnelled through a PCN domain such that the ECN marking should be tunnelled through a PCN domain such that the ECN marking
is hidden from the PCN control and PCN marking is applied only to is hidden from the PCN control and PCN marking is applied only to
the outer header. the outer header.
o add PCN markings to the ECN field if applications wish to receive o add PCN markings to the ECN field if applications wish to receive
the PCN markings for whatever purpose. In that case IPsec tunnels the PCN markings for whatever purpose. In that case IPsec tunnels
should be used for tunnelling. This, however, must be done only should be used for tunnelling. This, however, must be done only
skipping to change at page 10, line 26 skipping to change at page 10, line 36
[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.
8.2. Informative References 8.2. Informative References
[I-D.ietf-pcn-3-in-1-encoding]
Briscoe, B., Moncaster, T., and M. Menth, "Encoding 3 PCN-
States in the IP header using a single DSCP",
draft-ietf-pcn-3-in-1-encoding-09 (work in progress),
March 2012.
[Menth09f] [Menth09f]
Menth, M., Babiarz, J., and P. Eardley, ""Pre-Congestion Menth, M., Babiarz, J., and P. Eardley, "Pre-Congestion
Notification Using Packet-Specific Dual Marking" in Notification Using Packet-Specific Dual Marking",
Proceedings of the International Workshop on the Network Proceedings of the International Workshop on the Network
of the Future (Future-Net), IEEE, Dresden, Germany", of the Future (Future-Net), IEEE, Dresden, Germany,
June 2009. June 2009.
[ecn-pcn-usecases] [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Sarker, Z. and I. Johansson, "Usecases and Benefits of end Notification", RFC 6040, November 2010.
to end ECN support in PCN Domains",
draft-sarker-pcn-ecn-pcn-usecases-01 (work in progress),
May 2008.
Authors' Addresses Authors' Addresses
Michael Menth Michael Menth
University of Wuerzburg University of Tuebingen
room B206, Institute of Computer Science Department of Computer Science
Am Hubland Sand 13
Wuerzburg D-97074 Tuebingen D-72076
Germany Germany
Phone: +49 931 31 86644 Phone: +49 07071 29 70505
Email: menth@informatik.uni-wuerzburg.de Email: menth@informatik.uni-tuebingen.de
URI: http://www.kn.inf.uni-tuebingen.de
Jozef Babiarz Jozef Babiarz
Nortel Networks 3inova Networks Inc
3500 Carling Avenue CRC Innovation Centre
Ottawa K2H 8E9 Bldg 94 Room 216D
3701 Carling Avenue
Ottawa K2H 8S2
Canada Canada
Phone: +1-613-763-6098 Phone: +1-613-298-0438
Email: babiarz@nortel.com Email: j.babiarz@3inovanetworks.com
Toby Moncaster Toby Moncaster
BT University of Cambridge
B54/70, Adastral Park Computer Laboratory
Martlesham Heath JJ Thomson Avenue
Ipswich IP5 3RE Cambridge CB3 0FD
UK UK
Phone: +44 1473 648734 Phone: +44 1223 763654
Email: toby.moncaster@bt.com Email: toby@moncaster.com
URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/
Bob Briscoe Bob Briscoe
BT & UCL 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
Email: bob.briscoe@bt.com Email: bob.briscoe@bt.com
URI: http://www.bobbriscoe.net
 End of changes. 28 change blocks. 
57 lines changed or deleted 68 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/