draft-ietf-pcn-psdm-encoding-00.txt   draft-ietf-pcn-psdm-encoding-01.txt 
Congestion and Pre Congestion M. Menth Congestion and Pre Congestion M. Menth
Internet-Draft University of Wuerzburg Internet-Draft University of Wuerzburg
Intended status: Experimental J. Babiarz Intended status: Experimental J. Babiarz
Expires: December 28, 2009 Nortel Networks Expires: September 6, 2010 Nortel Networks
T. Moncaster T. Moncaster
BT BT
B. Briscoe B. Briscoe
BT & UCL BT & UCL
June 26, 2009 March 5, 2010
PCN Encoding for Packet-Specific Dual Marking (PSDM) PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding)
draft-ietf-pcn-psdm-encoding-00 draft-ietf-pcn-psdm-encoding-01
Abstract
Pre-congestion notification (PCN) is a link-specific and load-
dependent packet re-marking mechanism and provides in Differentiated
Services networks feedback to egress nodes about load conditions
within the domain. It is used to support admission control and flow
termination decision in a simple way. This document proposes how PCN
marks can be encoded into the IP header for packet-specific dual
marking (PSDM). PSDM encoding provides three different codepoints:
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
to PM.
Status
This memo is posted as an Internet-Draft with an intent to eventually
be published as an experimental RFC.
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. 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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 2, line 9
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 December 28, 2009. This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document proposes how PCN marks can be encoded into the IP described in the BSD License.
header. The presented encoding reuses the ECN field of the Voice-
Admit DSCP in a single PCN domain. The encoding of unmarked PCN
packets indicates whether they are subject to either excess- or
exhaustive-marking. This is useful, e.g., when data and probe
packets require different marking mechanisms.
Status
This memo is posted as an Internet-Draft with an intent to eventually
be published as an experimental RFC.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Encoding for Packet-Specific Dual Marking . . . . . . . . . . . 4 3. Encoding for Packet-Specific Dual Marking . . . . . . . . . . 6
3.1. Proposed Encoding and Expected Node Behavior . . . . . . . 4 3.1. Proposed Encoding and Expected Node Behavior . . . . . . . 6
3.1.1. PCN Codepoints . . . . . . . . . . . . . . . . . . . . 5 3.1.1. PCN Codepoints . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Codepoint Handling by PCN Ingress Nodes . . . . . . . . 5 3.1.2. Codepoint Handling by PCN Ingress Nodes . . . . . . . 6
3.1.3. Codepoint Handling by PCN Interfaces . . . . . . . . . 5 3.1.3. Codepoint Handling by PCN Interfaces . . . . . . . . . 6
3.1.4. Codepoint Handling by PCN Egress Nodes . . . . . . . . 5 3.1.4. Codepoint Handling by PCN Egress Nodes . . . . . . . . 7
3.2. Reasons for the Proposed Encoding . . . . . . . . . . . . . 6 3.2. Reasons for the Proposed Encoding . . . . . . . . . . . . 7
3.2.1. Problems with DSCPs . . . . . . . . . . . . . . . . . . 6 3.2.1. Scarcity of DSCPs . . . . . . . . . . . . . . . . . . 7
3.2.2. Problems with Tunneling . . . . . . . . . . . . . . . . 6 3.2.2. Problems with Tunneling . . . . . . . . . . . . . . . 7
3.2.3. Problems with the ECN Field . . . . . . . . . . . . . . 7 3.2.3. Problems with the ECN Field . . . . . . . . . . . . . 8
3.3. Handling of ECN Traffic . . . . . . . . . . . . . . . . . . 7 3.3. Handling of ECN Traffic . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 8 7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Pre-congestion notification provides information to support admission The objective of Pre-Congestion Notification (PCN) [RFC5559] is to
control and flow termination at the boundary nodes of a Diffserv protect the quality of service (QoS) of inelastic flows within a
region in order to protect the quality of service (QoS) of inelastic Diffserv domain, in a simple, scalable, and robust fashion. Two
flows [PCN-arch]. This is achieved by marking packets on interior mechanisms are used: admission control (AC), to decide whether to
nodes according to some metering function implemented at each node. admit or block a new flow request, and (in abnormal circumstances)
Excess traffic marking marks PCN packets that exceed a certain flow termination (FT) to decide whether to terminate some of the
reference rate on a link while exhaustive marking marks all PCN existing flows. To achieve this, the overall rate of PCN-traffic is
packets on a link when the PCN traffic rate exceeds a reference rate metered on every link in the domain, and PCN-packets are
[PCN-marking-behaviour]. These marks are monitored by the egress 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 notification").
The level of marking allows boundary nodes to make decisions about
whether to admit or terminate. This is achieved by marking packets
on interior nodes according to some metering function implemented at
each node. Excess-traffic-marking marks PCN packets that exceed a
certain reference rate on a link while threshold marking marks all
PCN packets on a link when the PCN traffic rate exceeds a lower
reference rate [RFC5670]. These marks are monitored by the egress
nodes of the PCN domain. nodes of the PCN domain.
This document proposes how PCN marks can be encoded into the IP This document proposes how PCN marks can be encoded into the IP
header. The presented encoding reuses the ECN field of the Voice- header when packet-specific dual marking (PSDM) is used to re-mark
Admit DSCP in a single PCN domain. The encoding of unmarked PCN packets [Menth09f]. That means, both excess-traffic-marking and
packets indicates whether they are subject to either excess- or threshold-marking are activated on the links within a PCN domain, but
exhaustive-marking. Therefore, we call this proposal encoding for packets are subject to re-marking by only one of them. The encoding
packet-specific dual marking (PSDM). of unmarked PCN packets indicates whether they are subject to either
excess-traffic-marking (not-ETM) or threshold-marking (not-ThM) and
they may be re-marked to PCN-marked (PM).
PSDM supports exhaustive marking and excess marking as long as PSDM encoding can be applied in networks implementing
individual packets are subject to only one of them. It can be
applied in networks implementing
o only AC based on exhaustive marking (reference rate = admissible o only AC based on threshold-marking (reference rate = PCN-
rate), admissible-rate),
o only FT based on excess marking (reference rate = supportable o only FT based on excess-traffic-marking (reference rate = PCN-
rate), supportable-rate),
o both AC and FT based on excess marking (reference rate = o both AC and FT based on excess-traffic-marking (reference rate =
admissible rate) PCN-admissible-rate)
o Probe-based AC based on exhaustive marking (reference rate = o Probe-based AC based on threshold-marking (reference rate = PCN-
admissible rate) and FT based on excess marking (reference rate = admissible-rate) and FT based on excess-traffic-marking (reference
supportable rate). rate = PCN-supportable-rate)[Menth09f].
Although the motivation for this encoding scheme is to exhaustive- The motivation for PSDM encoding is that probe packets are subject
mark probe packets and to excess-mark data packets, routers do not only to threshold-marking and that data packets are subject only to
need to differentiate explicitly between probe and data packets since excess-traffic-marking. Nevertheless, routers should not need to
packets are a priori marked with an appropriate codepoint indicating differentiate explicitly between probe and data packets since packets
the marking mechanism applying to them. are a priori marked with an appropriate codepoint (not-ETM, not-ThM)
indicating the marking mechanism applying to them.
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
[PCN-arch]. The following additional terms are defined in this [RFC5559]. The following additional terms are defined in this
document: document:
o Exhaustive marking - generalization of threshold and ramp marking
o PCN-capable flow - a flow subject to PCN-based admission control o PCN-capable flow - a flow subject to PCN-based admission control
and or flow termination and/or flow termination
o PCN-enabled DSCP - DSCP indicating within a PCN domain that o PCN-enabled DSCP - DSCP indicating within a PCN domain that
packets possibly belong to a PCN-capable flow packets possibly belong to a PCN-capable flow
o PCN-capable ECN codepoint (PCN codepoint) - DSCP set to a PCN- o PCN-capable ECN codepoint (PCN codepoint) - DSCP set to a PCN-
enabled DSCP and ECN field set to a codepoint indicating that a enabled DSCP and ECN field set to a codepoint indicating that a
packet belongs to a PCN-capable flow (not-ExM, not-EhM, or M, packet belongs to a PCN-capable flow (not-ThM, not-ETM, or PM,
explained below) explained below)
o PCN packet - a packet belonging to a PCN capable flow within a PCN o PCN packet - a packet belonging to a PCN capable flow within a PCN
domain, must have a PCN-enabled DSCP and a PCN-capable ECN domain, must have a PCN-enabled DSCP and a PCN-capable ECN
codepoint codepoint
o not-PCN capable (not-PCN) - new ECN codepoint for packets of non- o not-PCN capable (not-PCN) - new ECN codepoint for packets of non-
PCN-capable flows when a PCN-enabled DSCP is set PCN-capable flows when a PCN-enabled DSCP is set
o not-excess-marked (not-ExM) - new ECN codepoint for unmarked PCN o not-excess-traffic-marked (not-ETM) - new ECN codepoint for
packets that are subject to excess marking unmarked PCN packets that are subject to excess-traffic-marking
o not-exhaustive-marked (not-EhM) - new ECN codepoint for unmarked o not-threshold-marked (not-ThM) - new ECN codepoint for unmarked
PCN packets that are subject to exhaustive marking PCN packets that are subject to threshold-marking
o marked (M) - new ECN codepoint for marked PCN packets regardless o PCN-marked (PM) - new ECN codepoint for re-marked PCN packets
whether they were subject to excess or exhaustive marking. regardless whether they were subject to excess-traffic-marking or
threshold-marking.
3. Encoding for Packet-Specific Dual Marking 3. Encoding for Packet-Specific Dual Marking
In this section the encoding for packet-specific single marking In this section the encoding for packet-specific dual marking (PSDM)
(PSDM) is presented and the reasons for the proposed design are is presented and the reasons for the proposed design are outlined.
outlined.
3.1. Proposed Encoding and Expected Node Behavior 3.1. Proposed Encoding and Expected Node Behavior
The encoding reuses the Voice-Admit DSCP [voice-admit] as a PCN- The encoding reuses a PCN-enabled DSCP to indicate packets of PCN-
enabled DSCP to indicate packets of PCN-capable flows within a PCN capable flows within a PCN domain.
domain. So far, this is the only DSCP considered for that use, but
this encoding scheme is easily extensible towards multiple PCN-
enabled DSCPs.
3.1.1. PCN Codepoints 3.1.1. PCN Codepoints
The ECN field of packets with a PCN-enabled DSCP is interpreted The ECN field of packets with a PCN-enabled DSCP is interpreted
within a PCN domain as PCN codepoint while it is interpreted as ECN within a PCN domain as PCN codepoint while it is interpreted as ECN
codepoint outside PCN domains. Four new PCN codepoints are defined codepoint outside PCN domains. Four new PCN codepoints are defined
in Table 1. in Figure 1. PSDM encoding can be seen as an extension of baseline
encoding [RFC5696]
+------------------+---------+---------+---------+----+ +--------+----------------------------------------------------+
| DSCP | 00 | 10 | 01 | 11 | | | Codepoint in ECN field of IP header |
+------------------+---------+---------+---------+----+ | DSCP | (RFC3168 codepoint name) |
| PCN-enabled DSCP | not-PCN | not-ExM | Not-EhM | M | | +--------------+-------------+-------------+---------+
+------------------+---------+---------+---------+----+ | | 00 (Not-ECT) | 10 (ECT(0)) | 01 (ECT(1)) | 11 (CE) |
+--------+--------------+-------------+-------------+---------+
| DSCP n | not-PCN | not-ETM | not-ThM | PM |
+--------+--------------+-------------+-------------+---------+
Table 1: Mapping of PCN codepoints into the ECN field Figure 1: PSDM encoding.
3.1.2. Codepoint Handling by PCN Ingress Nodes 3.1.2. Codepoint Handling by PCN Ingress Nodes
When packets belonging to PCN flows arrive at the ingress router of When packets belonging to PCN flows arrive at the ingress router of
the PCN domain, the ingress router first drops all CE-marked packets. the PCN domain, the ingress router first drops all CE-marked packets.
Then, it sets the DSCP of the remaining PCN packets to an PCN-enabled Then, it sets the DSCP of the remaining PCN packets to an PCN-enabled
DSCP and re-marks the ECN field of all PCN packets that are subject DSCP and re-marks the ECN field of all PCN packets that are subject
to exhaustive marking to not-EhM (e.g. probe packets), and all PCN to threshold-marking to not-ThM (e.g. probe packets), and all PCN
packets that are subject to excess marking to not-ExM (e.g. data packets that are subject to excess-traffic-marking to not-ETM (e.g.
packets). If packets with a PCN-enabled DSCP arrive that belong to data packets). If packets with a PCN-enabled DSCP arrive that belong
non-PCN flows, the PCN ingress node re-marks their ECN field to not- to non-PCN flows, the PCN ingress node re-marks their ECN field to
PCN. not-PCN or re-marks their DSCP to a different one while preserving
the contents of the ECN field.
3.1.3. Codepoint Handling by PCN Interfaces 3.1.3. Codepoint Handling by PCN Interfaces
If the meter for excess marking of a PCN node indicates that a PCN If the meter for excess-traffic-marking of a PCN node indicates that
packet should be marked, its ECN field is set to marked (M) only if a PCN packet should be re-marked, its ECN field is set to PCN-marked
it was not-ExM before. If the meter for exhaustive marking of a PCN (PM) only if it was not-ETM before. If the meter for threshold-
node indicates that a PCN packet should be marked, its ECN field is marking of a PCN node indicates that a PCN packet should be re-
set to marked (M) only if it was not-EhM before. marked, its ECN field is set to PCN-marked (PM) only if it was not-
ThM before.
3.1.4. Codepoint Handling by PCN Egress Nodes 3.1.4. Codepoint Handling by PCN Egress Nodes
If the egress node of a PCN domain receives a marked PCN packet, it If the egress node of a PCN domain receives a PM-packet, it infers
infers somehow whether the packet was not-ExM or not-EhM by the PCN somehow whether the packet was not-ETM or not-ThM by the PCN ingress
ingress node to interpret the marking. This can be done as probe node to interpret the marking. This can be done as probe packets
packets must be distinguishable from PCN data packets. The egress must be distinguishable from PCN data packets anyway. The egress
node resets the ECN field of all packets with PCN-enabled DSCPs to node resets the ECN field of all packets with PCN-enabled DSCPs to
not-ECT. This breaks the ECN capability for all flows with PCN- not-ECT. This breaks the ECN capability for all flows with PCN-
enabled DSCPs, regardless whether they are PCN-capable or not. enabled DSCPs, regardless whether they are PCN-capable or not.
Appropriate tunnelling across a PCN domain can preserve the ECN Appropriate tunnelling across a PCN domain can preserve the ECN
marking of packets with PCN-enabled DSCPs and the ECN-capability of marking of packets with PCN-enabled DSCPs and the ECN-capability of
their flows (see Section 3.3). their flows (see Section 3.3). When the DSCPs in the headers of
packets belonging to flows with PCN-enabled DSCPs have been changed
to another DSCP, the egress node should reverse that change.
3.2. Reasons for the Proposed Encoding 3.2. Reasons for the Proposed Encoding
3.2.1. Problems with DSCPs 3.2.1. Scarcity of DSCPs
DSCPs are a scarce resource in the IP header such that at most one DSCPs are a scarce resource in the IP header so that at most one
should be used for PCN. To avoid the requirement for a new DSCP, the should be used for PCN encoding.
Voice-Admit DSCP is reused. To differentiate pure Voice-Admit
traffic from PCN traffic within a PCN domain, pure Voice-Admit
traffic has its ECN field set to not-PCN within a PCN domain. The
encoding should be extensible towards different data plane priorities
for PCN traffic in PCN domains which requires different PCN-enabled
DSCPs, one for each priority level.
3.2.2. Problems with Tunneling 3.2.2. Problems with Tunneling
The encoding scheme must cope with tunnelling within PCN domains. The encoding scheme must cope with tunnelling within PCN domains.
However, various tunnelling schemes limit the persistence of ECN However, various tunnelling schemes limit the persistence of ECN
marks in the top-most IP header to a different degree. Two IP-in-IP marks in the top-most IP header to a different degree. Two IP-in-IP
tunnelling modes are defined in [RFC3168] and a third one in tunnelling modes are defined in [RFC3168] and a third one in
[RFC4301] for IP-in-IPsec tunnels. [RFC4301] for IP-in-IPsec tunnels.
The limited-functionality option in [RFC3168] requires that the ECN The limited-functionality option in [RFC3168] requires that the ECN
codepoint in the outer header is set to not-ECT such that ECN is codepoint in the outer header is set to not-ECT so that ECN is
disabled for all tunnel routers, i.e., they drop packets instead of disabled for all tunnel routers, i.e., they drop packets instead of
mark them in case of congestion. The tunnel egress just decapsulates mark them in case of congestion. The tunnel egress just decapsulates
the packet and leaves the ECN codepoints of the inner packet header the packet and leaves the ECN codepoints of the inner packet header
unchanged. unchanged.
o This mode protects the inner IP header from being PCN-marked upon o This mode protects the inner IP header from being PCN-marked upon
decapsulation. It can be used to tunnel ECN marks across PCN decapsulation. It can be used to tunnel ECN marks across PCN
domains such that PCN marking is applied to the outer header domains such that PCN marking is applied to the outer header
without affecting the inner header. without affecting the inner header.
skipping to change at page 7, line 6 skipping to change at page 8, line 16
The full-functionality option in [RFC3168] requires that the ECN The full-functionality option in [RFC3168] requires that the ECN
codepoint in the outer header is copied from the inner header unless codepoint in the outer header is copied from the inner header unless
the inner header codepoint is CE. In this case, the outer header the inner header codepoint is CE. In this case, the outer header
codepoint is set to ECT(0). This choice has been made to disable the codepoint is set to ECT(0). This choice has been made to disable the
ECN fields of the outer header as a covert channel. Upon ECN fields of the outer header as a covert channel. Upon
decapsulation, the ECN codepoint of the inner header remains decapsulation, the ECN codepoint of the inner header remains
unchanged unless the outer header ECN codepoint is CE. In this case, unchanged unless the outer header ECN codepoint is CE. In this case,
the inner header codepoint is also set to CE. This preserves outer the inner header codepoint is also set to CE. This preserves outer
header information if it is CE. However, the fact that CE marks of header information if it is CE. However, the fact that CE marks of
the inner header are not visible in the outer header may be a problem the inner header are not visible in the outer header may be a problem
for excess marking as it takes already marked traffic into account for excess-traffic-marking as it takes already marked traffic into
and for some required packet drop policies. account and for some required packet drop policies.
Tunnelling with IPSec copies the inner header ECN bits to the outer Tunnelling with IPsec copies the inner header ECN field to the outer
header ECN bits RFC4301, Sect. 5.1.2.1 [RFC4301] upon encapsulation. header ECN field RFC4301, Sect. 5.1.2.1 [RFC4301] upon encapsulation.
Upon decapsulation, CE-marks of the outer header are copied into the Upon decapsulation, CE-marks of the outer header are copied into the
inner header, the other marks are ignored. With this tunnelling inner header, the other marks are ignored. With this tunnelling
mode, CE marks of the inner header become visible to all meters, mode, CE marks of the inner header become visible to all meters,
markers, and droppers for tunnelled traffic. In addition, limited markers, and droppers for tunnelled traffic. In addition, limited
information from the outer header is propagated into the inner information from the outer header is propagated into the inner
header. Therefore, only IPSec tunnels should be used inside PCN header. Therefore, only IPsec tunnels should be used inside PCN
domains when ECN bits are reused for PCN encoding. Another domains when ECN bits are reused for PCN encoding. Another
consequence is that CE is the only codepoint that can be used to consequence is that CE is the only codepoint to which packets can be
indicate a marked packet beyond tunnelling. re-marked along a tunnel within a PCN domain so that the changed
codepoint survives decapsulation.
3.2.3. Problems with the ECN Field 3.2.3. Problems with the ECN Field
The guidelines in [RFC4774] describe how the ECN bits can be reused The guidelines in [RFC4774] describe how the ECN bits can be reused
while being compatible with [RFC3168]. A CE mark of a packet must while being compatible with [RFC3168]. A CE mark of a packet must
never be changed to another ECN codepoint. Furthermore, a not-ECT never be changed to another ECN codepoint. Furthermore, a not-ECT
mark of a packet must never be changed to one of the ECN-capable mark of a packet must never be changed to one of the ECN-capable
codepoints ECT(0), ECT(1), or CE. Care must be taken that this rule codepoints ECT(0), ECT(1), or CE. Care must be taken that this rule
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 Voice-Admit packets must be dropped before entering a all CE-marked PCN packets must be dropped before entering a PCN
PCN domain and the ECN field of all Voice-Admit packets must be set domain and the ECN field of all PCN packets must be reset to not-ECT
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 adapatation there are plans to reuse ECN signals for rate adaptation
[ecn-pcn-usecases]. Therefore, two different options might be [ecn-pcn-usecases]. 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
if end systems are ECN capable and signal that they wish to if end systems are ECN capable and signal that they wish to
receive this additional PCN marking information. If this is receive this additional PCN marking information. If this is
useful, the required signalling needs to be defined. useful, the required signalling needs to be defined.
Both options are an independent of the way how PCN marks are encoded. Both options are an independent of the way how PCN marks are encoded.
Therefore, they are not in the scope of this document. Therefore, they are not in the scope of this document.
4. IANA Considerations 4. IANA Considerations
This document makes no request to IANA. It does however suggest a This document makes no request to IANA.
change to the ([RFC3168]) behaviour for the ECN field for the Voice-
Admit [voice-admit] DSCP within a PCN domain.
5. Security Considerations 5. Security Considerations
{ToDo} {ToDo}
6. Conclusions 6. Conclusions
This document describes an encoding scheme with the following This document describes an encoding scheme with the following
benefits: {ToDo} benefits: {ToDo}
skipping to change at page 8, line 38 skipping to change at page 9, line 47
addressed to the IETF PCN working group mailing list <pcn@ietf.org>, addressed to the IETF PCN working group mailing list <pcn@ietf.org>,
and/or to the authors. and/or to the authors.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the [RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124, Explicit Congestion Notification (ECN) Field", BCP 124,
RFC 4774, November 2006. RFC 4774, November 2006.
8.2. Informative References [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009.
[PCN-arch] [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
Eardley, P., "Pre-Congestion Notification Architecture", Nodes", RFC 5670, November 2009.
draft-ietf-pcn-architecture-03 (work in progress),
February 2008.
[PCN-marking-behaviour] [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Eardley, P., "Marking behaviour of PCN-nodes", Encoding and Transport of Pre-Congestion Information",
draft-eardley-pcn-marking-behaviour-01 (work in progress), RFC 5696, November 2009.
June 2008.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 8.2. Informative References
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [Menth09f]
Internet Protocol", RFC 4301, December 2005. Menth, M., Babiarz, J., and P. Eardley, ""Pre-Congestion
Notification Using Packet-Specific Dual Marking" in
Proceedings of the International Workshop on the Network
of the Future (Future-Net), IEEE, Dresden, Germany",
June 2009.
[ecn-pcn-usecases] [ecn-pcn-usecases]
Sarker, Z. and I. Johansson, "Usecases and Benefits of end Sarker, Z. and I. Johansson, "Usecases and Benefits of end
to end ECN support in PCN Domains", to end ECN support in PCN Domains",
draft-sarker-pcn-ecn-pcn-usecases-01 (work in progress), draft-sarker-pcn-ecn-pcn-usecases-01 (work in progress),
May 2008. May 2008.
[voice-admit]
Baker, F., Polk, J., and M. Dolly, "DSCPs for Capacity-
Admitted Traffic",
draft-ietf-tsvwg-admitted-realtime-dscp-04 (work in
progress), February 2008.
Authors' Addresses Authors' Addresses
Michael Menth Michael Menth
University of Wuerzburg University of Wuerzburg
room B206, Institute of Computer Science room B206, Institute of Computer Science
Am Hubland Am Hubland
Wuerzburg D-97074 Wuerzburg D-97074
Germany Germany
Phone: +49 931 888 6644 Phone: +49 931 31 86644
Email: menth@informatik.uni-wuerzburg.de Email: menth@informatik.uni-wuerzburg.de
Jozef Babiarz Jozef Babiarz
Nortel Networks Nortel Networks
3500 Carling Avenue 3500 Carling Avenue
Ottawa K2H 8E9 Ottawa K2H 8E9
Canada Canada
Phone: +1-613-763-6098 Phone: +1-613-763-6098
Email: babiarz@nortel.com Email: babiarz@nortel.com
 End of changes. 50 change blocks. 
164 lines changed or deleted 181 lines changed or added

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