draft-ietf-pcn-baseline-encoding-06.txt   draft-ietf-pcn-baseline-encoding-07.txt 
Congestion and Pre Congestion T. Moncaster Congestion and Pre Congestion T. Moncaster
Internet-Draft B. Briscoe Internet-Draft B. Briscoe
Intended status: Standards Track BT Intended status: Standards Track BT
Expires: March 8, 2010 M. Menth Expires: March 29, 2010 M. Menth
University of Wuerzburg University of Wuerzburg
September 4, 2009 September 25, 2009
Baseline Encoding and Transport of Pre-Congestion Information Baseline Encoding and Transport of Pre-Congestion Information
draft-ietf-pcn-baseline-encoding-06 draft-ietf-pcn-baseline-encoding-07
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 8, 2010. This Internet-Draft will expire on March 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 31 skipping to change at page 2, line 31
encoding described here provides only two PCN encoding states: not- encoding described here provides only two PCN encoding states: not-
marked and PCN-marked. Future extensions to this encoding may be marked and PCN-marked. Future extensions to this encoding may be
needed in order to provide more than one level of marking severity. needed in order to provide more than one level of marking severity.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6
3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 6 3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 6
3.1. List of Abbreviations . . . . . . . . . . . . . . . . . . 7 3.1. List of Abbreviations . . . . . . . . . . . . . . . . . . 7
4. Encoding two PCN States in IP . . . . . . . . . . . . . . . . 7 4. Encoding two PCN States in IP . . . . . . . . . . . . . . . . 8
4.1. Marking Packets . . . . . . . . . . . . . . . . . . . . . 8 4.1. Marking Packets . . . . . . . . . . . . . . . . . . . . . 9
4.2. Valid and Invalid Codepoint Transitions . . . . . . . . . 8 4.2. Valid and Invalid Codepoint Transitions . . . . . . . . . 9
4.3. Rationale for Encoding . . . . . . . . . . . . . . . . . . 9 4.3. Rationale for Encoding . . . . . . . . . . . . . . . . . . 10
4.4. PCN-Compatible Diffserv Codepoints . . . . . . . . . . . . 10 4.4. PCN-Compatible Diffserv Codepoints . . . . . . . . . . . . 10
4.4.1. Co-existence of PCN and not-PCN traffic . . . . . . . 10 4.4.1. Co-existence of PCN and not-PCN traffic . . . . . . . 11
5. Rules for Experimental Encoding Schemes . . . . . . . . . . . 11 5. Rules for Experimental Encoding Schemes . . . . . . . . . . . 11
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. PCN Deployment Considerations (Informational) . . . . 14 Appendix A. PCN Deployment Considerations (Informational) . . . . 15
A.1. Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 14 A.1. Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 15
A.2. Rationale for Using ECT(0) for Not-marked . . . . . . . . 15 A.2. Rationale for Using ECT(0) for Not-marked . . . . . . . . 16
Appendix B. Co-existence of PCN and ECN (Informational) . . . . . 17
1. Introduction 1. Introduction
The objective of the Pre-Congestion Notification (PCN) Architecture The objective of the Pre-Congestion Notification (PCN) Architecture
[RFC5559] is to protect the quality of service (QoS) of inelastic [RFC5559] is to protect the quality of service (QoS) of inelastic
flows within a Diffserv domain, in a simple, scalable and robust flows within a Diffserv domain, in a simple, scalable and robust
fashion. The overall rate of the PCN-traffic is metered on every fashion. The overall rate of the PCN-traffic is metered on every
link in the PCN-domain, and PCN-packets are appropriately marked when link in the PCN-domain, and PCN-packets are appropriately marked when
certain configured rates are exceeded. These configured rates are certain configured rates are exceeded. These configured rates are
below the rate of the link thus providing notification before any below the rate of the link thus providing notification before any
skipping to change at page 3, line 31 skipping to change at page 3, line 31
header by re-using the bits of the Explicit Congestion Notification header by re-using the bits of the Explicit Congestion Notification
(ECN) field [RFC3168]. It also describes how packets are identified (ECN) field [RFC3168]. It also describes how packets are identified
as belonging to a PCN-flow. Some deployment models require two PCN as belonging to a PCN-flow. Some deployment models require two PCN
encoding states, others require more. The baseline encoding encoding states, others require more. The baseline encoding
described here only provides for two PCN encoding states. However described here only provides for two PCN encoding states. However
the encoding can be easily extended to provide more states. Rules the encoding can be easily extended to provide more states. Rules
for such extensions are given in Section 5. for such extensions are given in Section 5.
Changes from previous drafts (to be removed by the RFC Editor): Changes from previous drafts (to be removed by the RFC Editor):
From -06 to -07:
Changes made following IESG review comments.
Changed Section 4 and added Appendix B to clarify the correct
behaviour when handling packets that already have values other
than not-ECT in their ECN field.
Added paragraph to end of Section 6 clarifying that a PCN-domain
has "hard" edges.
From -05 to -06: From -05 to -06:
Extensive changes to the text following IETF Last Call and Gen-ART Extensive changes to the text following IETF Last Call and Gen-ART
review comments. review comments.
Abstract updated following mailing list discussions after Gen-ART Abstract updated following mailing list discussions after Gen-ART
review by Spencer Dawkins. review by Spencer Dawkins.
Added list of abbreviations Added list of abbreviations
skipping to change at page 4, line 11 skipping to change at page 4, line 23
Section 5. Removed any ambiguity about meaning of PCN-marked in Section 5. Removed any ambiguity about meaning of PCN-marked in
such a context. Added requirements for experimental schemes to such a context. Added requirements for experimental schemes to
define which meter causes which mark. define which meter causes which mark.
Clarified text in Section 6 relating to support for e2e ECN. Clarified text in Section 6 relating to support for e2e ECN.
Added text in Section 8 relating to injection of PCN-marks into Added text in Section 8 relating to injection of PCN-marks into
the PCN-domain. the PCN-domain.
Changed text of Appendix A.1 to reflect comments from Spencer Changed text of Appendix A.1 to reflect comments from Spencer
Dawkins and Philip Eardey. Dawkins and Philip Eardley.
From -04 to -05: From -04 to -05:
Clarified throughout that the PCN WG is not requesting a specific Clarified throughout that the PCN WG is not requesting a specific
DSCP for PCN. Rather we are recommending a set of DSCPs that DSCP for PCN. Rather we are recommending a set of DSCPs that
might be suitable. Appendix A.1 has been re-written to reflect might be suitable. Appendix A.1 has been re-written to reflect
this. References to maintaining a list of PCN-compatible DSCPs this. References to maintaining a list of PCN-compatible DSCPs
have also been removed. have also been removed.
Last sentence of Section 6 altered. Last sentence of Section 6 altered.
skipping to change at page 8, line 16 skipping to change at page 8, line 39
The following rules apply to all PCN traffic: The following rules apply to all PCN traffic:
o PCN-traffic MUST be marked with a PCN-compatible Diffserv o PCN-traffic MUST be marked with a PCN-compatible Diffserv
Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be
chosen that are already defined for use with admission controlled chosen that are already defined for use with admission controlled
traffic. Appendix A.1 gives guidance to implementors on suitable traffic. Appendix A.1 gives guidance to implementors on suitable
DSCPs. Guidelines for mixing traffic-types within a PCN-domain DSCPs. Guidelines for mixing traffic-types within a PCN-domain
are given in [I-D.ietf-pcn-marking-behaviour]. are given in [I-D.ietf-pcn-marking-behaviour].
o Any packet that is not-PCN but which shares the same Diffserv o Any packet arriving at the PCN-ingress that shares a PCN-
codepoint as PCN-enabled traffic MUST have its ECN field set to compatible DSCP and is not-PCN MUST be marked as not-PCN within
00. the PCN-domain.
o If a packet arrives at the PCN-ingress with its ECN field already
set to a value other than not-ECT, then appropriate action MUST be
taken to meet the requirements of [RFC3168]. The simplest
appropriate action is to just drop such packets. However this is
a drastic action that an operator may feel is undesirable.
Appendix B provides more information and summarises other
alternative actions that might be taken.
4.1. Marking Packets 4.1. Marking Packets
[I-D.ietf-pcn-marking-behaviour] states that any encoding scheme [I-D.ietf-pcn-marking-behaviour] states that any encoding scheme
document must specify the required action to take if one of the document must specify the required action to take if one of the
marking algorithms indicates that a packet needs to be marked. For marking algorithms indicates that a packet needs to be marked. For
the baseline encoding scheme the required action is simply as the baseline encoding scheme the required action is simply as
follows: follows:
o If a marking algorithm indicates the need to mark a PCN-packet o If a marking algorithm indicates the need to mark a PCN-packet
skipping to change at page 12, line 5 skipping to change at page 12, line 32
The baseline encoding specified in this document defines PCN- The baseline encoding specified in this document defines PCN-
compatible Diffserv codepoints as no longer supporting the default compatible Diffserv codepoints as no longer supporting the default
ECN semantics. As such this document is compatible with BCP 124. ECN semantics. As such this document is compatible with BCP 124.
On its own, this baseline encoding cannot support both ECN marking On its own, this baseline encoding cannot support both ECN marking
end to end and PCN marking within a PCN-domain. It is possible to do end to end and PCN marking within a PCN-domain. It is possible to do
this by carrying e2e ECN across a PCN domain within the inner header this by carrying e2e ECN across a PCN domain within the inner header
of an IP in IP tunnel, or by using a richer encoding such as the of an IP in IP tunnel, or by using a richer encoding such as the
proposed experimental scheme in [I-D.ietf-pcn-3-state-encoding]. proposed experimental scheme in [I-D.ietf-pcn-3-state-encoding].
In any PCN deployment, traffic can only enter the PCN-Domain through
PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress-
nodes ensure that any packets entering the PCN- domain have the ECN-
field in their outermost IP header set to the appropriate PCN
codepoint. PCN-egress-nodes then guarantee that the ECN-field of any
packet leaving the PCN-domain has the correct ECN semantics. This
prevents leakage of ECN marks into or out of the PCN-domain and thus
reduces backward compatibility issues.
7. IANA Considerations 7. IANA Considerations
This document makes no request to IANA. This document makes no request to IANA.
8. Security Considerations 8. Security Considerations
PCN-marking only carries a meaning within the confines of a PCN- PCN-marking only carries a meaning within the confines of a PCN-
domain. This encoding document is intended to stand independently of domain. This encoding document is intended to stand independently of
the architecture used to determine how specific packets are the architecture used to determine how specific packets are
authorised to be PCN-marked, which will be described in separate authorised to be PCN-marked, which will be described in separate
skipping to change at page 16, line 24 skipping to change at page 17, line 13
outside the controlled PCN-domain). outside the controlled PCN-domain).
o Incremental deployment: Either codepoint is suitable providing o Incremental deployment: Either codepoint is suitable providing
that the codepoints are used consistently. that the codepoints are used consistently.
o Conceptual consistency with other schemes: ECT(0) is conceptually o Conceptual consistency with other schemes: ECT(0) is conceptually
consistent with [RFC3168]. consistent with [RFC3168].
Overall this seemed to suggest ECT(0) was most appropriate to use. Overall this seemed to suggest ECT(0) was most appropriate to use.
Appendix B. Co-existence of PCN and ECN (Informational)
This baseline encoding scheme redefines the ECN codepoints within the
PCN-domain. As packets with a PCN-compatible DSCP leave the PCN-
domain, their ECN field is reset to not-ECT (00). This is a problem
for the operator if packets with a PCN-compatible DSCP arrive at the
PCN-domain with any ECN codepoint other than not-ECN. If the ECN-
codepoint is ECT(0) (10) or ECT(1) (01), resetting the ECN field to
00 effectively turns off end-to-end ECN. This is undesirable as it
removes the benefits of ECN but [RFC3168] states it is no worse than
dropping the packet. However, if a packet was marked with CE (11),
resetting the ECN field to 00 at the PCN egress node violates the
rule that CE-marks must never be lost except as a result of packet
drop [RFC3168].
A number of options exist to overcome this issue. The most
appropriate option will depend on the circumstances and has to be a
decision for the operator. The definition of the action is beyond
the scope of this document but we briefly explain the four broad
categories of solution below: tunnelling the packets, using an
extended encoding scheme, signalling to the end-systems to stop using
ECN or re-marking packets to a different DSCP.
o Tunnelling the packets across the PCN-domain (for instance in an
IP-in-IP tunnel from the PCN-ingress-node to the PCN-egress-node)
preserves the original ECN marking on the inner header.
o An extended encoding scheme can be designed that preserves the
original ECN codepoints. For instance if the PCN-egress-node can
determine from the PCN codepoint what the original ECN codepoint
was then it can reset the packet to that codepoint.
[I-D.ietf-pcn-3-state-encoding] partially achieves this but is
unable to recover ECN markings if the packet is PCN-marked in the
PCN-domain.
o Explicit signalling to the end systems can indicate to the source
that ECN cannot be used on this path (because it does not support
ECN & PCN at the same time). Dropping the packet can be thought
of as a form of silent signal to the source as it will see any
ECT-marked packets it sends being dropped.
o Packets that are not-PCN but which share a PCN-compatible DSCP can
be re-marked to a different local-use DSCP at the PCN-ingress-node
with the original DSCP restored at the PCN-egress. This preserves
the ECN codepoint on the packets, but it relies on there being
spare local-use DSCPs within the PCN-domain.
Authors' Addresses Authors' Addresses
Toby Moncaster Toby Moncaster
BT BT
B54/70, Adastral Park B54/70, Adastral Park
Martlesham Heath Martlesham Heath
Ipswich IP5 3RE Ipswich IP5 3RE
UK UK
Phone: +44 1473 648734 Phone: +44 1473 648734
 End of changes. 14 change blocks. 
22 lines changed or deleted 98 lines changed or added

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