One document matched: draft-chan-pcn-encoding-comparison-00.txt
PCN K. Chan
Internet-Draft Nortel
Intended status: Informational G. Karagiannis
Expires: January 3, 2008 University of Twente
July 2, 2007
Pre-Congestion Notification Encoding Comparison
draft-chan-pcn-encoding-comparison-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 January 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
DiffServ mechanisms have been developed to support Quality of Service
(QoS). However, the level of assurance that can be provided with
DiffServ without substantial over-provisioning is limited. Pre-
Congestion Notification (PCN) investigates the use of per-flow
admission control to provide the required service guarantees for the
admitted traffic. While admission control will protect the QoS under
normal operating conditions, an additional flow termination mechanism
Chan & Karagiannis Expires January 3, 2008 [Page 1]
Internet-Draft Document July 2007
is necessary in the times of heavy congestion (e.g. caused by route
changes due to link or node failure).
Encoding and their transport are required to carry the congestion and
pre-congestion information from the congestion and pre-congestion
points to the decision points. This document provides a survey of
several encoding methods, using comparisons amongst them as a way to
explain their strengths and weaknesses.
Table of Contents
1. Motivation and Goals . . . . . . . . . . . . . . . . . . . . . 4
2. PCN Encoding Requirements and Features in current PCN
Detection, Marking, and Transport Mechanisms . . . . . . . . . 6
2.1. Supported PCN Features and Encoding States in CL-PHB
Method . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Supported PCN Features and Encoding States in Three
State PCN Marking Method . . . . . . . . . . . . . . . . . 8
2.3. Supported PCN Features and Encoding States in Single
Marking Method . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Supported PCN Features and Encoding States in Load
Control Method . . . . . . . . . . . . . . . . . . . . . . 9
3. Survey of Encoding and Transport Methods . . . . . . . . . . . 9
3.1. Encoding and Transport Using Both ECN and DSCP Fields . . 12
3.1.1. Option 1 Encoding . . . . . . . . . . . . . . . . . . 12
3.1.2. Option 2 Encoding . . . . . . . . . . . . . . . . . . 13
3.1.3. Option 3 Encoding . . . . . . . . . . . . . . . . . . 13
3.1.4. Option 4 Encoding . . . . . . . . . . . . . . . . . . 14
3.2. Encoding and Transport Using ECN Field . . . . . . . . . . 15
3.2.1. Option 5 Encoding . . . . . . . . . . . . . . . . . . 15
3.2.2. Option 6 Encoding . . . . . . . . . . . . . . . . . . 16
3.2.3. Option 7 Encoding . . . . . . . . . . . . . . . . . . 16
3.2.4. Option 8 Encoding . . . . . . . . . . . . . . . . . . 17
3.2.5. Option 9 Encoding . . . . . . . . . . . . . . . . . . 17
3.3. Encoding and Transport Using DSCP Field . . . . . . . . . 18
3.3.1. Option 10 Encoding . . . . . . . . . . . . . . . . . . 18
3.3.2. Option 11 Encoding . . . . . . . . . . . . . . . . . . 18
3.4. Encoding and Transport Using IPFIX . . . . . . . . . . . . 19
4. Encoding Comparison . . . . . . . . . . . . . . . . . . . . . 19
4.1. Comparison Criteria . . . . . . . . . . . . . . . . . . . 20
4.1.1. Co-Existence of PCN and Non-PCN Traffic . . . . . . . 20
4.1.2. Supported PCN Features . . . . . . . . . . . . . . . . 20
4.1.3. Required Encoding States/Modes . . . . . . . . . . . . 20
4.1.4. Encoding Implementation Requirements . . . . . . . . . 21
4.1.5. Different ECN Semantics Capability . . . . . . . . . . 21
4.1.6. Old Router Impacts . . . . . . . . . . . . . . . . . . 21
4.1.7. Alternate-ECN Traffic Performance . . . . . . . . . . 22
Chan & Karagiannis Expires January 3, 2008 [Page 2]
Internet-Draft Document July 2007
4.2. Encoding and Transport Comparison . . . . . . . . . . . . 23
4.2.1. Co-Existence of PCN and Non-PCN Traffic . . . . . . . 23
4.2.2. Supported PCN Features . . . . . . . . . . . . . . . . 23
4.2.3. Supported Encoding States/Modes . . . . . . . . . . . 24
4.2.4. Encoding Implementation Requirements . . . . . . . . . 26
4.2.5. Different ECN Semantics Capability . . . . . . . . . . 27
4.2.6. Old Router Impacts . . . . . . . . . . . . . . . . . . 27
4.2.7. Alternate-ECN Traffic Performance . . . . . . . . . . 27
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 28
6. Security Implications . . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Current PCN Detection, Marking and Transport
Mechanisms . . . . . . . . . . . . . . . . . . . . . 29
Appendix A.1. Detection, Marking and Transport Mechanisms in
CL-PHB . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A.2. Detection, Marking and Transport Mechanisms in
Three State Marking . . . . . . . . . . . . . . . . 30
Appendix A.3. Detection, Marking and Transport Mechanisms in
Single Marking . . . . . . . . . . . . . . . . . . . 30
Appendix A.4. Detection, Marking and Transport Mechanisms in
Load Control Marking . . . . . . . . . . . . . . . . 31
9. Informative References . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 36
Chan & Karagiannis Expires January 3, 2008 [Page 3]
Internet-Draft Document July 2007
1. Motivation and Goals
IP networks were initially designed to perform per IP packet
forwarding treatment without discrimination. With the increased use
of the IP network by applications with different transport functional
requirement, the notion of Quality of Service (QoS) was introduced
[21].
DiffServ [10] introduced differentiated per packet forwarding
treatment to provide QoS: some packets are served at a higher
scheduling priority than others. Diffserv Service Classes [19]
categorises various DiffServ traffic and recommends how they can be
used for packets from applications with different transport
requirements. For instance there are Telephony and Real-time
Interactive service classes. Applications like these need low loss,
low delay and low jitter. A suitable Per Hop Behavior (PHB) is
Expedited Forwarding (EF) [16], which works by assuring that packets
(usually) encounter very short or empty queues. Each router is
allocated a certain amount of bandwidth for the EF PHB, for instance.
Excess packets are dropped and delayed, thus leading to poorer QoS
for an end user running an application like voice-over-IP. Even if
average traffic levels are known, due to traffic variations the level
of assurance that can be provided with DiffServ without substantial
over-provisioning is limited.
To help ensure that the average traffic loads remain within the
allocated bandwidth limits, the DiffServ Architecture [10] introduces
the idea of policing the amount of traffic in a class as it enters
the network. The acceptable traffic level is described by a traffic
conditioning agreement (TCA). However, TCAs police the aggregate
traffic in a class at the network ingress, and for scalability
reasons typically includes traffic to different destinations. As a
result, TCA's do not guarantee that EF aggregate at any given node in
the network does not exceed the allocated capacity [23], and so don't
ensure that a particular end user's QoS is guaranteed. Also, in
practice TCAs are static and so require accurate and/or conservative
prediction of the traffic matrix. Also, in practice the TCA at the
ingress must allow any destination address, if it is to remain
scalable.
To cope with the issue of exceeding bandwidth allocation to EF on
some links, in practice a policer or shaper is assumed to be
installed at the interior nodes as well. However, shaping or
policing traffic causes excess packets be dropped and delayed, thus
leading to poorer QoS for an end user running an application like
voice-over-IP. Even if average traffic levels remain within the
allocated bandwidth limits, traffic variations may limit the level of
assurance that can be provided with DiffServ without substantial
Chan & Karagiannis Expires January 3, 2008 [Page 4]
Internet-Draft Document July 2007
over-provisioning.
These factors motivate us to work on per flow admission control for a
DiffServ network, and in particular on measurement-based admission
control, ie new flow requests are blocked dynamically in response to
actual (incipient) congestion on a router within the DiffServ
network.
However, despite flow admission control, sometimes there can be heavy
congestion - for example caused by link or node failure that
effectively reduces the network's capacity. The default option is
that the QoS of all flows is degraded. However, by terminating some
flows the QoS of the remaining flows can be protected. The work
reported in I-D.silverman-tsvwg-mlefphb indicates that in the context
where calls have different recongizable precedence levels (e.g. in
the context of military/emergency calls [22]), this problem can be
partially addressed by dropping lower-precednce calls preferentially
while protecting higher precedence calls. However, as it was shown
in [6], the need to terminate some flows of a given precedence level,
while protecting the QoS of the rest of the flows of this precedence
level remains.
This motivates us to work on per flow termination for a DiffServ
network, and in particular on measurement-based termination, ie
existing on-going flows are dropped dynamically in response to actual
congestion on a router within the DiffServ network.
Explicit Congestion Notification (ECN) [15] introduced the idea of a
router indicating that it is congested by changing the header of
packets ("marking" them). However, ECN in RFC3168 [15] is designed
for TCP applications. This motivates us to develop the concept for
real-time applications. A router "PCN-marks" packets as an early
warning of its incipient congestion ("pre-congestion"). These
markings are then used by the admission control and termination
mechanisms.
The main goal of this document is a survey and comparison of several
encoding and transport methods that are required to encode the pre-
congestion information and to transport it from the PCN interior
nodes to the decision PCN egress nodes. In order to accomplish this
comparison, a number of criteria are developed. The possible
encoding and transport methods are:
o Encoding and transport using the combination of the ECN and DSCP
bits of a data packet header
o Encoding and transport using the ECN bits of a data packet header
Chan & Karagiannis Expires January 3, 2008 [Page 5]
Internet-Draft Document July 2007
o Encoding and transport using the DSCP bits of a data packet header
o Encoding and transport using a different channel than data packets
The rest of this document is organized as follows. Section 2
describes the encoding requirements indicated by currently known
detection and marking mechanisms that can be used within the PCN-
domain. Section 3 describes a survey of the possible encoding and
transport methods. The comparison of these methods is accomplished
in Section 4 and Section 5 provides the conclusion. The rest of the
sections describe the security considerations, acknowledgements, IANA
considerations and references.
2. PCN Encoding Requirements and Features in current PCN Detection,
Marking, and Transport Mechanisms
In order to derive a number of encoding and transport methods it is
important to be aware of which PCN based mechanisms are used for
congestion and pre-congestion detection and marking. Therefore, this
section describes the PCN encoding and transport features and the
encoding modes/states that are possible in the current available PCN
based algorithms used for congestion and pre-congestion detection and
marking in interior nodes. The current PCN detection, marking and
transport mechanisms are briefly introduced in the Appendix of this
document and are discussed in detail in CL PHB [5], Single-Marking
[3], Three-State-Marking [2] and Load-Control [4].
The main PCN features that can be supported by the PCN based
algorithms introduced in the Appendix of this document are:
o "admission control", see PCN-Architecture [1]
o "flow termination", see PCN-Architecture [1]
o "not congested", used to identify/notify that a congestion and/or
a pre-congestion situation has not occurred in a certain
communication path.
o "ECMP handling", used to solve the ECMP problem that is related to
the fact that flows that are not passing through a congested PCN
interior node can belong to an aggregate that detects a
congestion. Any measures that are taken on such flows will not
solve the congestion problem, since such flows are not
contributing and causing the congestion on the PCN interior node.
Furthermore, it is important to emphasize that in general, dealing
with the ECMP handling during flow termination, could be somewhat
Chan & Karagiannis Expires January 3, 2008 [Page 6]
Internet-Draft Document July 2007
disjoint from how a detection and marking algorithm operates. For
example:
1. The CL-PHB [5] and/or Single-Marking [3] algorithm, similar to
the Load-Control [4] algorithm, could use the "Affected Marking",
encoding mode/state, see Appendix A.4, to solve the ECMP problem
at the expense of an additional DSCP value and the expense of
keeping track of which flows have been Affected Marked and which
have not.
2. The CL-PHB [5] and/or Single-Marking [3] algorithm, similar to
the Three-State-Marking [2] algorithm, could choose for
termination only flows which have been Termination Marked at the
expense of additional complexity at the edge of needing to keep
track of which flows have been Termination Marked or not.
2.1. Supported PCN Features and Encoding States in CL-PHB Method
In CL-PHB [5], see also Appendix A.1, a solution has been developed
that can be used in PCN-domains, to provide the admission control and
flow termination features. Furthermore, this algorithm can support
the "not congested" feature, which is used to notify that a
congestion and/or a pre-congestion situation has not occurred in a
certain communication path.
The algorithm currently specified in CL-PHB [5] does not specify if
and how the "ECMP handling" feature is supported. Therefore, it can
be deduced that currently, CL-PHB [5] supports the following main PCN
supported encoding features: the "not congested", "admission
control", and the "flow termination".
The congestion and precongestion information is mainly encoded and
transported by using the combination of the ECN and DSCP field
carried in the IP header of the data packets. The used PCN encoding
and transport modes/states are:
o "Admission Marking" used by the "admission control" feature
o "Termination Marking" used by the "flow termination" feature
Due to the fact that among others, ECN bits are used to transport the
congestion and pre-congestion information, the ECN-nonce modes/states
have to also be transported. In particular, the ECN-nonce modes/
states are used to support the "not congested" feature. Furthermore,
the "Not-ECN capable" mode/state needs to be used in order to
indicate to a node that the traffic is not ECN-capable. The Explicit
Congestion Notification (ECN)-nonce is an optional addition to ECN
that protects against accidental or malicious concealment of marked
Chan & Karagiannis Expires January 3, 2008 [Page 7]
Internet-Draft Document July 2007
packets from the TCP sender. It uses the two ECN-Capable Transport
(ECT) codepoints in the ECN field of the IP header. It improves the
robustness of congestion control by enabling co-operative senders to
prevent receivers from exploiting ECN to gain an unfair share of
network bandwidth. The ECN-Capable Transport (ECT) codepoints '10'
and '01' (ECT(0) and ECT(1) respectively) are set by the data sender
to indicate that the end-points of the transport protocol are ECN-
capable.
In particular, the main encoding scheme used in CL-PHB [5] is given
by Option 1 in Figure 1.
2.2. Supported PCN Features and Encoding States in Three State PCN
Marking Method
The solution proposed in Three-State-Marking [2] supports the
"admission control", "flow termination", and "not congested"
features. Furthermore this solution can also support the "ECMP
handling" feature during the flow termination process. This feature
can be provided using the explicit excess load marking approach, a
marked packet belongs to a flow that was routed through congested
router. Therefore an additional marking mode/state for the support
of the "ECMP handling" feature is not needed.
Thus the main PCN supported encoding modes/states are:
o "Admission Marking" used by the "admission control" feature
o "Termination Marking" used by the "flow termination" and "ECMP
handling" features.
o "Not congested Marking" used by the "not congested" feature.
The exact method of transporting the congestion and precongestion
information is not specified in Three-State-Marking [2], but the
method given by Option 1 in Figure 1 (or number of other encoding
options) can be used.
2.3. Supported PCN Features and Encoding States in Single Marking
Method
The solution proposed in Single-Marking [3], see also Appendix A.3,
supports the "admission control" and "flow termination" and "not
congested" features. The algorithm currently specified in Single-
Marking [3], similar to the algorithm specified in CL-PHB [5], does
not specify if and how the "ECMP handling" feature is supported.
The way of how the congestion and precongestion information is
Chan & Karagiannis Expires January 3, 2008 [Page 8]
Internet-Draft Document July 2007
transported is not described in Single-Marking [3], but it is
emphasized that it can be similar to the transportation way used in
CL-PHB [5]. As mentioned in Section 2.1, due to the fact that among
others, ECN bits are used to transport the congestion and pre-
congestion information, the ECN-nonce modes and Not ECN-capable mode
have to also be transported. Thus the main PCN supported encoding
modes/states are:
o "Admission Marking" used by the "admission control" and "flow
termination" features.
A possible way of how the encoding scheme can be implemented for the
Single-Marking [3] mechanism is given by Option 3 (or number of other
encoding options) in Figure 1.
2.4. Supported PCN Features and Encoding States in Load Control Method
The algorithm proposed in Load-Control [4], see also Appendix A.4,
supports the "admission control", "flow termination", "not congested"
and "ECMP handling" features. Note that this algorithm provides
solutions to the ECMP problem that can occur during either the
admission control or the flow termination process.
The congestion and precongestion information is transported by using
the DSCP field carried in the IP header of the data packets. Thus
the main PCN supported encoding modes/states are:
o "Admission Marking" used by the "admission control" feature
(Encoding Option 10, see section 3.3.1).
o "Termination (or Encoded) Marking" used by the "flow termination"
feature (and in Encoding Option 11, see section 3.3.2, also used
by the "admission control" feature).
o "Not congested Marking" used by the "not congested" feature.
o "Affected Marking" that in combination with the ""Termination (or
Encoded) Marking" is used to support the "ECMP handling" feature.
In particular, the main encoding scheme used in Load-Control [4] is
given by Option 10 and Option 11 in Figure 1. With details provided
in section 3.3.1 and 3.3.2.
3. Survey of Encoding and Transport Methods
There are many choices available for encoding the PCN information.
To provide a summary and an overview, we use the following table of
Chan & Karagiannis Expires January 3, 2008 [Page 9]
Internet-Draft Document July 2007
current proposed encodings. Clarifying the abreviation and
normiclature used in the table and some description of each of these
encoding choices and their trade-offs are in subsequent sub sections.
-----------------------------------------------------------------------
| ECN Bits || 00 | 01 | 10 | 11 || DSCP |
|==============++==========+==========+==========+==========++==========|
| RFC 3168 || Not-ECT | ECT(1) | ECT(0) | CE || NA |
|==============++==========+==========+==========+==========++==========|
| Option 1 || AM | ECT(1) | ECT(0) | TM || PCN |
|--------------++----------+----------+----------+----------++----------|
| Option 2 || AM | ECT(A) | ECT(T) | TM || PCN |
|--------------++----------+----------+----------+----------++----------|
| Option 3 || Not-ECT | ECT(1) | ECT(0) | AM/TM || PCN |
|--------------++----------+----------+----------+----------++----------|
| Option 4 || Not-ECT | ECT(1) | ECT(0) | AM || PCN+TM |
|==============++==========+==========+==========+==========++==========|
| Option 5 || Not-ECT | ECT(1) | ECT(0) | AM or TM || NA |
|--------------++----------+----------+----------+----------++----------|
| Option 6 || Not-ECT | ECT(A) | ECT(T) | AM/TM || NA |
|--------------++----------+----------+----------+----------++----------|
| Option 7 || AM | ECT(A) | ECT(T) | TM || NA |
|--------------++----------+----------+----------+----------++----------|
| Option 8 || Not-CE | AM | PM | NDS-CE || NA |
|--------------++----------+----------+----------+----------++----------|
| Option 9 || Not-ECT | ECT | AM | TM || NA |
|==============++==========+==========+==========+==========++==========|
| Option 10 || NA | NA | NA | NA || 4 DSCP |
|--------------++----------+----------+----------+----------++----------|
| Option 11 || NA | NA | NA | NA || 3 DSCP |
-----------------------------------------------------------------------
Figure 1: Encoding of PCN Information in IP Header
Notes for Figure 1: Options 10 and 11 use different DSCPs to encode
the PCN states, hence the indication of 4 DSCPs and 3 DSCPs (for 4
PCN states and 3 PCN states respectively). The NA under the ECN bits
simply means the use of the ECN bits are Not Applicable for these
options. Details on the 4 DSCPs and 3 DSCPs usage are provided in
sections 3.3.1 and 3.3.2 respectively.
The above table contains abreviations of terms, their meaning are as
follows:
o ECN Bits: This refers to the two bit field in the IP header
defined by RFC 3168 [15].
Chan & Karagiannis Expires January 3, 2008 [Page 10]
Internet-Draft Document July 2007
o DSCP: DiffServ Code Point. This refers to the six bit field in
the IP header defined by RFC 2474 [10].
o Not-ECT: Not ECN Capable Transport. Defined in RFC 3168 [15].
o ECT(0), ECT(1): ECN Capable Transport. Defined in RFC 3168 [15].
o CE: Congestion Experienced. Defined in RFC 3168 [15].
o NA: Not Applicable. Meaning this field is not used for this
encoding choice.
o AM: Admission Marked.
o TM: Termination Marked.
o PCN: The DSCP field uses a specific code point for PCN traffic.
o Not-CE: Not experiencing congestion. This have the same meaning
as ECT(0) and ECT(1), but without the cheater detection
functionality.
o NDS-CE: Not DiffServ capable traffic with congestion experienced.
The encoding states/modes required are
o PCN Capable Transport Marking, for separation from None PCN
Capable Transport
o Not congested Marking, for indicaton of No Congestion Indication
o Admission Marking, for indication of Flow Admission Information
o Termination Marking, for indication of Flow Termination
Information
o Nonce Marking, for cheater detection
o Affected Marking for ECMP indication
The possible encoding and transport methods are:
o Encoding and transport using the combination of the ECN and DSCP
bits of a data packet header
o Encoding and transport using the ECN bits of a data packet header
Chan & Karagiannis Expires January 3, 2008 [Page 11]
Internet-Draft Document July 2007
o Encoding and transport using the DSCP bits of a data packet header
o Encoding and transport using a different channel (e.g., IPFIX, see
RFC 3955 [18]) than the IP header of the data packets
The encoding table provided in Figure 1 is organized following the
general encoding method given above. With the exception of not
describing the "different channel" method. Following sub-sections
provide additional details to each of the Encoding Option choices.
Further more, some possible use of these encoding states are
summarized by the detection methods descriptions in Appendix A. But
we encourage the reader to read each of the PCN detection algorithm
drafts as continual improvements are made based on simulation work.
3.1. Encoding and Transport Using Both ECN and DSCP Fields
This section describes the Encoding Options that uses the combination
of ECN and DSCP bits available in the IP header of data packets to
encode the PCN states.
One feature of this group of Encoding Options sets them apart from
the others: They all use the inherent nature of DiffServ for traffic
class separation to fullfil the PCN Encoding State requirment of: PCN
Capable Transport Marking. This use of DiffServ and DSCP will also
satisfy the need to keep none PCN Capable traffic out of the PCN
Capable traffic class. Hence this group of Encoding Options will
view the rest of the required PCN encoding states/modes as being
subset of being part of PCN Capable traffic class.
Note that these encoding schemes are denoted in this document as
"Encoding Option 1", "Encoding Option 2", "Encoding Option 3", and
"Encoding Option 4". The transport of the congestion and pre-
congestion information is accomplished using the IP data packets.
3.1.1. Option 1 Encoding
As compared to the encoding indicated by RFC 3168 [15], because the
requirement for indicaton of PCN Capable traffic and None PCN Capable
traffic is being handled by DSCP, the "00" bit encoding is being used
for Admission Marking indication. Leaving the "11" for Termination
Marking indication. The Nonce Marking and the Not Congested Marking
requirement is provided by the use of ECT(1)/01 and ECT(0)/10.
Hence Encoding Option 1 statisfies PCN Encoding requirements of:
o PCN Capable Transport Marking, for separation from None PCN
Capable Transport
Chan & Karagiannis Expires January 3, 2008 [Page 12]
Internet-Draft Document July 2007
o Not congested Marking, for indicaton of No Congestion Indication
o Admission Marking, for indication of Flow Admission Information
o Termination Marking, for indication of Flow Termination
Information
o Nonce Marking, for cheater detection
With the PCN Encoding requirement not satisfied being:
o Affected Marking for ECMP indication
3.1.2. Option 2 Encoding
Encoding Option 2 builds on Encoding Option 1 and adds the additional
capability of the sender specifying interest of receiving Admission
Marking or Termination Marking information by using ECT(A)/01 and
ECT(T)/10. This additional control and separation of Admission and
Termination information may provide the PCN edge nodes added
capabilities, which are out of scope for this document.
As with Encoding Option 1, Encoding Option 2 statisfies PCN Encoding
requirements of:
o PCN Capable Transport Marking, for separation from None PCN
Capable Transport
o Not congested Marking, for indicaton of No Congestion Indication
o Admission Marking, for indication of Flow Admission Information
o Termination Marking, for indication of Flow Termination
Information
o Nonce Marking, for cheater detection
With the PCN Encoding requirement not satisfied being:
o Affected Marking for ECMP indication
3.1.3. Option 3 Encoding
Encoding Option 3 uses a single marking to represent both Admission
Information and Termination Information. This saving of a marking
code point allows the restoraton of None PCN Capable Transport
indicaton of Not-ECT/00. Allowing this encoding to look more like
the RFC 3168 [15] encoding (in encoding syntax, encoding semantax is
Chan & Karagiannis Expires January 3, 2008 [Page 13]
Internet-Draft Document July 2007
not represented here). But the None PCN Capable Transport
requirement is already provided for by the use of DiffServ and DSCP,
hence there is no additional functional difference with Encoding
Option 1 and 2.
Encoding Option 3 statisfies PCN Encoding requirements of:
o PCN Capable Transport Marking, for separation from None PCN
Capable Transport
o Not congested Marking, for indicaton of No Congestion Indication
o Admission Marking, for indication of Flow Admission Information
o Termination Marking, for indication of Flow Termination
Information
o Nonce Marking, for cheater detection
With the PCN Encoding requirement not satisfied being:
o Affected Marking for ECMP indication
3.1.4. Option 4 Encoding
Encoding Option 4 uses a new DSCP to indicate Termination
Information. Instead of using code point within the ECN bits. This
introducton of a new DSCP will require DiffServ to handle traffic
marked with this new DSCP the same way as all other PCN traffic.
Besides this difference, Encoding Option 4 is very much like Encoding
Option 5 and RFC 3168 [15]'s encoding.
Encoding Option 4 statisfies PCN Encoding requirements of:
o PCN Capable Transport Marking, for separation from None PCN
Capable Transport
o Not congested Marking, for indicaton of No Congestion Indication
o Admission Marking, for indication of Flow Admission Information
o Termination Marking, for indication of Flow Termination
Information
o Nonce Marking, for cheater detection
With the PCN Encoding requirement not satisfied being:
Chan & Karagiannis Expires January 3, 2008 [Page 14]
Internet-Draft Document July 2007
o Affected Marking for ECMP indication
3.2. Encoding and Transport Using ECN Field
This section describes the Encoding Options that uses only the ECN
bits available in the IP header of data packets to encode the PCN
states.
Please notice this group of Encoding Options does not use DiffServ at
all. Hence there are no separatoin of traffic based on their DSCP
values and DiffServ classes. With this group of Encoding Options,
the required states of "PCN Capable Transport"/"None PCN Capable
Transport" must be encoded using the ECN bits. Also, without the
protection/separation capability provided by DiffServ, it is
typically harder to satisfy the requirement set forth in RFC 4774
[20] for alternate ECN semantics.
Note that these encoding schemes are denoted in this document as
"Encoding Option 5", "Encoding Option 6", "Encoding Option 7", and
"Encoding Option 8". The transport of the congestion and pre-
congestion information is accomplished using the IP data packets.
3.2.1. Option 5 Encoding
Encoding Option 5 is actually identical to the encoding provided by
RFC 3168 [15]. With the option of using the bit pattern of 11 to
represent the AM or TM state. Encoding Option 5's simularity to RFC
3168 [15]'s encoding allows it to be easily understood by people who
understands RFC 3168 [15]. But at the same time, this gives it the
most difficulty when satisfying the requirements set forth in RFC
4774 [20] is needed.
The use of Not-ECT will separate PCN traffic from none PCN traffic
with the big exception of for ECN traffic.
Encoding Option 5 statisfies PCN Encoding requirements of:
o Not congested Marking, for indicaton of No Congestion Indication
o Admission Marking, for indication of Flow Admission Information
o Termination Marking, for indication of Flow Termination
Information
o Nonce Marking, for cheater detection
With the PCN Encoding requirement not satisfied being:
Chan & Karagiannis Expires January 3, 2008 [Page 15]
Internet-Draft Document July 2007
o PCN Capable Transport Marking, for separation from None PCN
Capable Transport
o Affected Marking for ECMP indication
3.2.2. Option 6 Encoding
Encoding Option 6 uses the ECT(A)/01 and ECT(T)/10 Markings to
indicate what kinds of information the sender wants, and hence
indicates if the CE/11 Marking indicates Admission or Termination
information.
But Encoding Option 6 suffers the same issue as Encoding Option 5 on
ability to separate traffic and indications between PCN and ECN
traffic. Hence they have the same problem satisfying the
requirements set forth in RFC 4774 [20].
Encoding Option 6 statisfies PCN Encoding requirements of:
o Not congested Marking, for indicaton of No Congestion Indication
o Admission Marking, for indication of Flow Admission Information
o Termination Marking, for indication of Flow Termination
Information
o Nonce Marking, for cheater detection
With the PCN Encoding requirement not satisfied being:
o PCN Capable Transport Marking, for separation from None PCN
Capable Transport
o Affected Marking for ECMP indication
3.2.3. Option 7 Encoding
Encoding Option 7 sacrafies the indication of None PCN Capable
Transport to allow the use of a different code point for indicating
Admission information. But this still suffers the same problems as
Encoding Options 5 and 6.
Encoding Option 7 statisfies PCN Encoding requirements of:
o Not congested Marking, for indicaton of No Congestion Indication
o Admission Marking, for indication of Flow Admission Information
Chan & Karagiannis Expires January 3, 2008 [Page 16]
Internet-Draft Document July 2007
o Termination Marking, for indication of Flow Termination
Information
o Nonce Marking, for cheater detection
With the PCN Encoding requirement not satisfied being:
o PCN Capable Transport Marking, for separation from None PCN
Capable Transport
o Affected Marking for ECMP indication
3.2.4. Option 8 Encoding
Encoding Option 8 gives up the ability to provide the Nonce
capability for allowing the indication of RFC 3168 [15] Congestion
Experienced (CE) and PCN indications at the same time. But then it
can not distinguish PCN/ECN Capable traffic from None PCN/ECN Capable
traffic, and still suffers the same issues as Encoding Options 5, 6,
and 7.
Encoding Option 8 statisfies PCN Encoding requirements of:
o Not congested Marking, for indicaton of No Congestion Indication
o Admission Marking, for indication of Flow Admission Information
o Termination Marking, for indication of Flow Termination
Information
With the PCN Encoding requirement not satisfied being:
o PCN Capable Transport Marking, for separation from None PCN
Capable Transport
o Nonce Marking, for cheater detection
o Affected Marking for ECMP indication
3.2.5. Option 9 Encoding
Encoding Option 9 gives up the ability to provide the Nonce
capability for allowing separate code points for Admission
information and Termination information. It also retains the ability
to indicate Not PCN Capable Transport. But it still suffers the lack
of ability to be distinguished from RFC 3168 [15] ECN traffic.
Encoding Option 9 statisfies PCN Encoding requirements of:
Chan & Karagiannis Expires January 3, 2008 [Page 17]
Internet-Draft Document July 2007
o Not congested Marking, for indicaton of No Congestion Indication
o Admission Marking, for indication of Flow Admission Information
o Termination Marking, for indication of Flow Termination
Information
With the PCN Encoding requirement not satisfied being:
o PCN Capable Transport Marking, for separation from None PCN
Capable Transport
o Nonce Marking, for cheater detection
o Affected Marking for ECMP indication
3.3. Encoding and Transport Using DSCP Field
In this type of encoding and transport method the congestion and
precongestion information is encoded into the 6 DSCP bits that are
transported in the IP header of the data packets. Two possible
alternatives can be distinguished, as indicated in the following sub-
sections.
3.3.1. Option 10 Encoding
Each of the encoding modes/states use a separate DSCP value, meaning
that when all encoding modes/states are supported then 4 DSCP values
are needed for encoding. Note that all DSCP values are representing
and are associated with the same PHB. The supported encoding modes/
states supported by this scheme are
o DSCP0 [original value] "Not congested Marking"
o DSCP1 [first additional experimental value] "Admission Marking"
o DSCP2 [second additional experimental value] "Termination
(Encoded) Marking"
o DSCP3 [third additional experimental value] "Affected marking"
3.3.2. Option 11 Encoding
Each of the "Not congested Marking", "Termination (Encoded) Marking"
and "Affected marking" modes/states use a different DSCP value. Note
that in this alternative the "termination (Encoded) Marking" mode/
state is used to support both the "admission control" and "flow
termination" features. This means that 3 DSCP values are needed for
Chan & Karagiannis Expires January 3, 2008 [Page 18]
Internet-Draft Document July 2007
encoding. Note that all DSCP values are representing and are
associated with the same PHB.
The supported encoding modes/states supported by this scheme are:
o DSCP0 [original value] "Not congested Marking"
o DSCP1 [first additional experimental value] "Termination (Encoded)
Marking"
o DSCP2 [second additional experimental value] "Affected marking"
3.4. Encoding and Transport Using IPFIX
In this type of encoding and transport method the congestion and
precongestion information can be encoded using the IPFIX protocol RFC
3955 [18], that is normally used to carry flow-based IP traffic
measurements from an observation point to a collecting point. Note
that this encoding scheme is denoted in this document as "IPFIX
channel". An observation point is a location in a network where IP
packets can be observed and measured. A collecting point can be a
process or a node that receives flow records from one or more
observation points. In the PCN case, each PCN-interior-node will be
an IPFIX observation point and the PCN-egress-node will be the IPFIX
collecting point.
The PCN-interior-node will support the metering process and the flow
records. Note that in this case each flow record can be associated
with the record of the congestion and pre-congestion metering
information associated with each PHB. The PCN-egress-node will then
support the IPFIX collecting process, which will receive flow records
from one or more congested and pre-congested PCN-interior-nodes.
Using this encoding method the encoding modes/states can be
aggregated and transported to the egress node by using the flow
records at regular intervals or at the moment that a congestion and
pre-congestion situation occurs. The used transport channel in this
case is not the data path but a signaling protocol.
4. Encoding Comparison
This section provides a comparison between the encoding and transport
methods described in Section 3. In order to do this comparison a
number of criteria are derived mainly by studying the current PCN
detection, marking and transport mechanisms described in Section 2.
Chan & Karagiannis Expires January 3, 2008 [Page 19]
Internet-Draft Document July 2007
4.1. Comparison Criteria
The following subsections describe a number of criteria that can be
used to compare the encoding and transport methods discussed in
Section 3.
4.1.1. Co-Existence of PCN and Non-PCN Traffic
This criterion emphasizes whether the used mechanisms allow the
coexistence of PCN traffic and of non-PCN traffic within the same
PCN-domain. The non-PCN traffic represents the traffic that cannot
become PCN marked and it belongs to another PHB than the PCN-traffic.
4.1.2. Supported PCN Features
This criterion is used to evaluate how many and which PCN features
are supported by an encoding and transport scheme. The PCN features
are:
o Not congested
o Admission control
o Flow termination
o ECMP handling
4.1.3. Required Encoding States/Modes
This criterion is used to evaluate how many and which encoding modes/
states are supported by an encoding scheme.
The possible PCN encoding modes are (note that some of them can be
combined):
o Not PCN-capable: - used to indicate to a node that the traffic is
not PCN- capable. By using this encoding mode a distinction can
be made between PCN- traffic and non PCN-traffic, see Section
4.1.1.
o "Not congested Marking", typically used to support the "not
congested" Feature
o "Admission marking", typically used to support the "admission
control" Feature
o "Termination marking", typically used to support the "flow
termination" feature
Chan & Karagiannis Expires January 3, 2008 [Page 20]
Internet-Draft Document July 2007
o "Affected Marking" used to support the "ECMP handling" feature.
When the ECN bits are used to transport the congestion and pre-
congestion information, the ECN-nonce modes and the Not ECN-capable
mode have to also be transported:
o ECT(1) marking
o ECT(0) marking
o Not ECN-capable - used to indicate to a node that the traffic is
not ECN-capable.
Note that the ECT(1) and ECT(0) modes/states are the ECN nonce modes/
states and are used to support the "not congested" feature.
4.1.4. Encoding Implementation Requirements
This criterion emphasizes the encoding implementation requirements,
regarding the need and the manner of using DSCPs, PHBs, ECN bits or
other type of encoding.
4.1.5. Different ECN Semantics Capability
This criterion is representing the first alternate ECN semantics
issue discussed in [RFC4774]. This criterion only applies to
encoding and transport schemes that are using the alternate ECN
semantics.
"(1) The first issue concerns how routers know which ECN semantics to
use with which packets in the network:
How does the connection indicate to the router that its packets are
using alternate ECN semantics? Is the specification of alternate-ECN
semantics robust and unambiguous? If not, is this a problem?
As an example, in most of the proposals for alternate ECN semantics,
a diffserv field is used to specify the use of alternate ECN
semantics. Do all routers that understand this diffserv codepoint
understand that it uses alternate ECN semantics, or not? Diffserv
allows routers to re-mark DiffServ Code Point (DSCP) values within
the network; what is the effect of this on the alternate ECN
semantics?" from [RFC4774]
4.1.6. Old Router Impacts
This criterion is representing the second and third alternate ECN
semantics issues discussed in [RFC4774]. This criterion only applies
Chan & Karagiannis Expires January 3, 2008 [Page 21]
Internet-Draft Document July 2007
to encoding and transport schemes that are using the alternate ECN
semantics.
"(2) A second issue is that of incremental deployment in a network
where some routers only use the default ECN semantics, and other
routers might not use ECN at all. In this document, we use the
phrase "new routers" to refer to the routers that understand the
alternate ECN semantics, and "old routers" to refer to routers that
don't understand or aren't willing to use the alternate ECN
semantics.
The possible existence of old routers raises the following question:
How does the possible presence of old routers affect the performance
of the alternate-ECN connections?
(3) The possible existence of old routers also raises the question of
how the presence of old routers affects the coexistence of the
alternate-ECN traffic with competing traffic on the path.", from
[RFC4774].
4.1.7. Alternate-ECN Traffic Performance
This criterion is the fourth alternate ECN semantics issue discussed
in [RFC4774]. This criterion only applies to encoding and transport
schemes that are using the alternate ECN semantics.
"(4) A final issue is that of the general evaluation of the alternate
ECN semantics:
How well does the alternate-ECN traffic perform, and how well does it
coexist with competing traffic on the path, in a "clean" environment
with new routers and with the unambiguous specification of the use of
alternate ECN semantics?", from [RFC4774]
In particular, the following detailed issues should be taken into
account:
o Verification of Feedback from the Router (see Section 5.1 in
[RFC4774])
o Coexistence with Competing Traffic (see Section 5.2 in [RFC4774])
o Proposals for Alternate ECN with Edge-to-Edge Semantics (see
Section 5.3 in [RFC4774])
o Encapsulated Packets (see Section 5.4 in [RFC4774])
Chan & Karagiannis Expires January 3, 2008 [Page 22]
Internet-Draft Document July 2007
o A General Evaluation of the Alternate ECN Semantics (see Section
5.5 in [RFC4774])
4.2. Encoding and Transport Comparison
This section describes the comparison of the encoding and transport
methods described in section 3, by using the criteria described in
Section 4.1. The encoding schemes are indicated in Figure 1.
The comparison is presented in the following way. Each subsection
describes a comparison of the encoding schemes indicated in Figure 1
based on one of the criteria introduced in Section 4.1.
4.2.1. Co-Existence of PCN and Non-PCN Traffic
The Encoding Option 9 scheme is the only scheme that is allowing the
coexistence of PCN and non-PCN traffic. The rest of the schemes
described in Section 3 are not allowing the coexistence of PCN and
non-PCN traffic. This can however, be realized when an additional
encoding mode/state is used, i.e., the Not PCN-capable mode described
in Section 4.2.3, which allows to distinguish between the non PCN-
traffic and the PCN-traffic. This additional encoding mode/state can
be realized by using DiffServ to separate the PCN traffic for all
other none PCN traffic.
4.2.2. Supported PCN Features
The Encoding Option 10, Encoding Option 11, and "IPFIX channel"
schemes can support the four PCN features: "not congested",
"Admission control", "Flow termination" and "ECMP handling".
The Encoding Option 1, Option 6, Option 2, Option 4, and Option 5
schemes are able to support the PCN features "not congested",
"admission control" and "flow termination". Furthermore, the Option
9 scheme can support the PCN features "admission control" and "flow
termination" and the Option 5 can support the "not congested" "flow
termination" and "ECMP handling" features.
Note that Encoding Option 1, Option 6, Option 2, Option 4, Option 9,
Option 5 (AM) could also support the "ECMP handling" feature, used
during the flow termination process, when the algorithm that uses
these encoding modes/states could choose for termination only flows
which have been Termination Marked at the expense of additional
complexity at the edge of needing to keep track of which flows have
been Termination Marked or not.
Chan & Karagiannis Expires January 3, 2008 [Page 23]
Internet-Draft Document July 2007
4.2.3. Supported Encoding States/Modes
The "IPFIX channel" solution does not use the encoding modes/states
listed in Section 4.1.3. This is because the "IPFIX channel"
encoding solution does not use the data path for encoding and
transport, but it requires to use a separate signaling channel to
transport the congestion and pre-congestion information associated
with the "not congested", "admission control", "flow termination" and
"ECMP handling" PCN features.
The "Not PCN-capable" encoding mode is not used by the presented
encoding schemes. However, if the separation between the PCN traffic
and non-PCN traffic is required, then the "Not PCN-capable" has to be
used by all schemes.
The "Not congested Marking" encoding mode is used by:
o Encoding Option 10
o Encoding Option 11
The "Admission Marking" encoding mode/state is used by:
o Encoding Option 10
o Encoding Option 11
o Encoding Option 1
o Encoding Option 6
o Encoding Option 2
o Encoding Option 4
o Encoding Option 9
o Encoding Option 5
The "Termination Marking" encoding mode/state is used by:
o Encoding Option 10
o Encoding Option 1
o Encoding Option 6
Chan & Karagiannis Expires January 3, 2008 [Page 24]
Internet-Draft Document July 2007
o Encoding Option 2
o Encoding Option 4
o Encoding Option 9
o Encoding Option 5
The "Affected Marking" encoding mode/state is used by:
o Encoding Option 10
o Encoding Option 11
The "ECN-nonce" encoding modes ((ECT(1) and ECT(0)) marking are used
by:
o Encoding Option 1
o Encoding Option 6
o Encoding Option 2
o Encoding Option 4
o Encoding Option 5A
o Encoding Option 5T
The "Not ECN-capable" encoding mode is used by:
o Encoding Option 1
o Encoding Option 6
o Encoding Option 2
o Encoding Option 4
o Encoding Option 9
o Encoding Option 5A
o Encoding Option 5T
Chan & Karagiannis Expires January 3, 2008 [Page 25]
Internet-Draft Document July 2007
4.2.4. Encoding Implementation Requirements
The "IPFIX channel" encoding mode needs a separate signaling channel
for the transport of the congestion and precongestion information
from the PCN-interior-nodes towards the PCN-egress-node. The
requirement of using an additional channel increases the complexity
and influences negatively the performance of the PCN-interior-nodes
since each PCN-interior-node needs to support in addition to the data
path a separate channel.
Encoding Option 10 and 11 (the DSCP-Alternatives) need to use in
addition to the original DSCP, three DSCP and two DSCP values,
respectively. These additional DSCP values can be taken from the
DSCP values that are not defined by standards action, see [8]. Note
that all the DSCP values are representing and are associated with one
PHB. Furthermore, if the separation between the PCN traffic and non-
PCN traffic is required, then an additional DSCP or PHB value is
needed for the "Not PCN-capable" encoding mode. The value of this
DSCP/PHB can either follow a standards action or use a value that is
applied for experimental or local use. It is important to note that
the number of the DSCP values used for local or experimental use is
restricted.
Encoding Options 1 to 9 (the ECN-Alternatives) need to take into
account, in addition to the PCN encoding modes also the encoding
modes that are specific to ECN, which are the "ECN nonce" and "Not
ECN-Capable" modes. Encoding Options 6, 9, 5A, 5T need to only use
the 4 ECN values. The use of the ECN values has to comply to
[RFC4774], see also Section 4.2.5, 4.2.6, 4.2.7. The rest of the
ECN-Alternatives, i.e., Option 1, 2, 3, 4 need to use the 4 ECN
values and one DSCP value. As mentioned above, the use of the ECN
values has to comply to [RFC4774], see also Section 4.2.5, 4.2.6,
4.2.7. Furthermore, the additional DSCP value can either be defined
using a standard action or by using, similar to Option 10 and 11 (the
DSCP-Alternatives), a DSCP value defined for experimental or local
use.
Furthermore, for all ECN-Alternatives, with exception to Option 9, an
additional DSCP or PHB value is needed for the encoding of the "Not
PCN-capable" mode. The value of this DSCP/PHB can either follow a
standards action or use a value that is applied for experimental or
local use. An alternative to using another DSCP, the points of view
of all traffic not DSCP marked with PCN may be considered "Not PCN-
capable". This may be applicable only to Encoding Options that uses
DIffServ.
Chan & Karagiannis Expires January 3, 2008 [Page 26]
Internet-Draft Document July 2007
4.2.5. Different ECN Semantics Capability
To satisfy the first alternate ECN semantics issue discussed in
[RFC4774] on "how does the connection indicate to the router that its
packets are using alternate ECN semantics?", the PCN traffic will
need to be distinguishable from the none PCN traffic and other ECN
traffic.
There are actually two issues indicated here. First: the ability to
distinguish PCN traffic from none PCN traffic. Second: the ability
to distinguish PCN traffic from ECN traffic.
For solving the first issue, the use of "Not-ECT" state to indicate
none PCN (also none ECN) traffic will be sufficient. But this does
not solve the second issue of distinguishing PCN traffic from ECN
traffic. The use of DSCP to distinguish PCN traffic from all other
traffic will solve both issues indicated.
With the use of a specific DSCP to indicate PCN traffic, encoding
Option 1, Option 2, Option 3, Option 4 of Figure 1 (Encoding of PCN
Information in IP Header) will satisfy this issue. The other
encoding Options will solve only one or the other issue, not solve
both issues.
4.2.6. Old Router Impacts
The second issue and the third issue raised by [RFC4774] is concerned
with the existence of both PCN routers and none PCN routers. The use
of a PCN DSCP allows the segregation of the PCN traffic away from the
other traffic. With the single PCN domain edge-to-edge deployment
scenario, all devices are at least DiffServ capable and controlled by
one management entity. With the use of the PCN DSCP, and correct
configuration of DiffServ, these two issues are resolved.
With the use of a specific DSCP to indicate PCN traffic, encoding
Option 1, Option 2, Option 3, Option 4 of Figure 1 (Encoding of PCN
Information in IP Header) will satisfy this issue. The other
encoding Options will solve only one or the other issue, not solve
both issues.
4.2.7. Alternate-ECN Traffic Performance
The forth issue raised by [RFC4774] is related to the performance of
the PCN semantics. This issue is more related to the marking
algorithm using the encoding to transport the PCN information. Hence
will not handle this issue until a later version of this document.
Chan & Karagiannis Expires January 3, 2008 [Page 27]
Internet-Draft Document July 2007
5. Conclusions
To Be Filled In After PCN List Discussions.
6. Security Implications
Packets from normal precedence and higher precedence sessions [22]
aren't distinguishable by PCN Interior Nodes. This prevents an
attacker specifically targeting, in the data plane, higher precedence
packets (perhaps for DoS or for eavesdropping). However, PCN End
Nodes can access this information to help decide whether to admit or
terminate a flow. The separation of network information provided by
the Interior Nodes and the precedence information at the PCN End
Nodes allows simpler, easier and better focused security enforcement.
PCN End Nodes police packets to ensure a flow sticks within its
agreed limit. This is similar to the existing IntServ behaviour.
Between them the PCN End Nodes must fully encircle the PCN-Region,
otherwise packets could enter the PCN-Region without being subject to
admission control, which would potentially destroy the QoS of
existing flows.
It is assumed that all the Interior Nodes and PCN End Nodes run PCN
and trust each other (ie the PCN-enabled Internet Region is a
controlled environment). For instance a non-PCN router wouldn't be
able to alert that it's suffering pre-congestion, which potentially
would lead to too many calls being admitted (or too few being
terminated). Worse, a rogue router could perform attacks such as
marking all packets so that no flows were admitted.
So security requirements are focussed at specific parts of the PCN-
Region:
The PCN End Nodes become the trust points. The degree of trust
required depends on the kinds of decisions it has to make and the
kinds of information it needs to make them. For example when the
PCN End Node needs to know the contents of the sessions for making
the decisions, when the contents are highly classified, the
security requirements for the PCN End Nodes involved will also
need to be high.
PCN-marking by the Interior Nodes along the packet forwarding path
needs to be trusted, because the PCN End Nodes rely on this
information.
Chan & Karagiannis Expires January 3, 2008 [Page 28]
Internet-Draft Document July 2007
7. IANA Considerations
To be completed.
8. Acknowledgements
To be completed.
Appendix A. Current PCN Detection, Marking and Transport Mechanisms
This appendix describes briefly the available PCN based mechanisms
that can be used for congestion and pre-congestion detection and
marking used at interior nodes. The following subsections focus on
the main characteristics of such algorithms that are influencing the
encoding and transport features, which are the encoding and marking
modes/states and the used transport channel. The current PCN
detection, marking and transport algorithms are discussed in detail
in CL-PHB [5], Single-Marking [3], Three-State-Marking [2] and Load-
Control [4].
Appendix A.1. Detection, Marking and Transport Mechanisms in CL-PHB
This section describes briefly the detection, marking and transport
algorithm specified in CL-PHB [5]. As a fundamental building block
to enable the admission control and flow termination algorithms, each
link of the PCN- domain is associated with a configured-admissible-
rate and configured-termination-rate; the former is usually
significantly larger than the latter. If traffic in a specific
DiffServ class ("PCN-traffic") on the link exceeds these rates then
packets are marked with "Admission-Marking" or "Termination-Marking".
To support the admission control algorithm, each PCN-interion-node in
the PCN-domain runs an algorithm to determine whether to Admission
Mark the packet. The algorithm measures the PCN-traffic on the link
and ensures that packets are admission marked before the actual queue
builds up. The algorithm's main parameter is the configured-
admissible-rate, which is set lower than the link speed. Admission
marked packets indicate that the PCN traffic rate is reaching the
configured-admissible-rate and so act as an "early warning" that the
engineered capacity is nearly reached. Therefore they indicate that
requests to admit prospective new PCN flows may need to be refused.
The Admission Marked and Termination Marked packets are transported
downstream towards the PCN-egress-node. The PCN-egress-node then
uses the received Admission Marked and Termination Marked pakets to
measure the Congestion-Level-Estimate for traffic from each remote
PCN-ingress-node. The Congestion-Level-Estimate is the number of
Chan & Karagiannis Expires January 3, 2008 [Page 29]
Internet-Draft Document July 2007
bits in PCN packets that are Admission marked or Termination marked,
divided by the number of bits in all PCN packets. It is calculated
by an PCN-egress-node separately for the PCN packets from each
particular PCN-ingress-node. This Congestion-Level-Estimate provides
an estimate of how near the links on the path inside the PCN-domain
are getting to the configured-admissible-rate. Subsequently, the
Congestion-Level-Estimate is signaled to the PCN-ingress-node. The
PCN-ingress-node uses the CLE value for admission control, i.e., when
the CLE is higher than a threshold then new flow requests are
rejected.
To support flow termination, each node in the PCN-domain runs an
algorithm to determine whether to Terminate Mark the packet. The
algorithm measures the PCN traffic and ensures that packets are
Termination Marked before the actual queue builds up. The
algorithm's main parameter is the configured-termination- rate, which
is set lower than the link speed (but higher than the configured-
admissible-rate). Thus termination marked packets are transported
downstream towards the PCN- egress-node to indicate that the PCN
traffic rate is reaching the configured- termination-rate and so act
as an "early warning" that the engineered capacity is nearly reached.
Therefore they indicate that it may be advisable to terminate some of
the existing PCN flows in order to preserve the QoS of the others.
The PCN-egress-node calculates also per ingress-egress aggregate the
Sustainable Admission Rate (SAR), which is actually the rate of the
received unmarked PCN-traffic. The SAR is sent to the PCN-ingress-
node that is used to calculate the amount of flows that have to be
terminated in order to stop the severe congestion situation. This is
accomplished by measuring, per ingress - egress aggregate, the PCN-
traffic that is destined for the specific PCN-egress-node and by
subtracting the SRA from it in order to calculate the excess amount
of PCN flows that have to be terminated.
Appendix A.2. Detection, Marking and Transport Mechanisms in Three
State Marking
Please see draft-babiarz-pcn-3sm-00.txt [2] for details on the Three
State Marking Algorithm.
Appendix A.3. Detection, Marking and Transport Mechanisms in Single
Marking
This section describes briefly the detection, marking and transport
algorithm specified in Single-Marking [3].
The PCN-Interior-node meters the PCN traffic and marks the excess
rate. It is important to note that only one single marking procedure
Chan & Karagiannis Expires January 3, 2008 [Page 30]
Internet-Draft Document July 2007
is needed for admission control and flow termination. The admission
marking rate is proportional to the excess rate above the configured-
admissible-rate. Since the rate at which admission has to be stopped
is preferably significantly lower than the rate at which flow
termination is required, which is the main argument for having two
different markings, the single marking solution has to provide for
different levels of admission and flow termination as well. To do
this the solution introduces a system-wide constant u which is the
ratio configured-termination-rate/configured-admissible-rate.
The PCN-egress-node measures the rate of both PCN marked and PCN
unmarked traffic on a per-ingress egress aggregate basis, and reports
to the PCN-ingress-node two values: the rate of PCN unmarked traffic
from this PCN-ingress-node, which is denoted as Sustainable Admission
Rate (SAR) and the Congestion Level Estimate (CLE), which is the
fraction of the marked traffic received from this PCN-ingress-node.
The SAR is calculated by measuring the amount of received PCN
unmarked rate. The Congestion Level Estimate (CLE) is calculated in
a similar way as specified in CL-PHB [5]. Both values are calculated
for each ingress-egress aggregate and they are reported to these PCN-
ingress-nodes. Each PCN-ingress-node calculates the Sustainable
Preemption Rate (SPR) by simply multiplying SAR with the system-wide
constant u. The termination (or pre-emption) of flows only takes
place when the rate of all flows sent by the PCN-ingress-node exceeds
the SPR. The number of flows to be terminated is calculated in the
following way. Per ingress - egress aggregate, the PCN-ingress-node
measures the PCN- traffic that is destined for the specific PCN-
egress-node and by subtracting the SPR from it in order to calculate
the excess amount of PCN flows that have to be terminated.
Appendix A.4. Detection, Marking and Transport Mechanisms in Load
Control Marking
This section describes briefly the detection, marking and transport
algorithm specified in Load-Control [4].
This algorithm is supporting the admission control and flow
termination features. The admission control feature based on probing
can be used to implement a simple measurement-based admission control
within a Diffserv domain. In these PCN-interior-nodes, thresholds
are set for the traffic belonging to different PHBs in the
measurement based admission control function. In this scenario an IP
packet is used as a probe packet, meaning that the DSCP field in the
header of the IP packet is re-marked when the predefined configured
admissible-rate is exceeded. When the predefined configured
admissible-rate is exceeded all packets are remarked by a node. In
this way also the data packets are marked to notify the PCN-egress-
Chan & Karagiannis Expires January 3, 2008 [Page 31]
Internet-Draft Document July 2007
node that a congestion occurred on a particular PCN-ingress-node to
PCN-egress-node path. The PCN edges can then admit or reject flows
that are requesting resources. The rate of the re-marked data
packets is used to detect a congestion situation that can influence
the admission control decisions.
By using probing, the ECMP problem that is associated with the
admission control feature can be, to a certain degree, solved by
being able to identify which flows are passing through the congested
node.
The flow termination feature is able to terminate flows in case of
exceptional events, such as severe congestion after re-routing. The
exceptional event, or severe congestion can be detected using a DSCP
remarking approach where the packet remarking is proportional to the
amount of unavailable resources. In particular, the Diffserv nodes
mark packets whenever the measured link throughput rate exceeds a
configured-termination-rate and the proportion of the marked packets
is in proportion to the excess traffic above the configured-
termination-rate threshold. This type of marking is denoted as
encoded marking and the marked packets are denoted as Encoded Marked
packets. It is important to note that any data packets that are
passing through the congested node and are not Encoded Marked are
marked differently using another DSCP value. This type of marking is
denoted as Affected Marking and the marked packets are denoted as
Affected Marked packets.
The PCN-egress-nodes can use the Encoded Marked packets to calculate
the percentage of throughput or bandwidth that does exceed the
configured-termination-rate threshold. The PCN-egress-node can then,
in combination with the PCN-ingress-node, the sender of the traffic
and the support of the PCN domain(s), reduce the generated
throughput, by terminating ongoing flows, until the configured-
termination-rate threshold is satisfied. Note that the PCN-egress-
node will select only flows that received Encoded Marked and Affected
Marked data packets. In this way the ECMP problem is solved by being
able to identify which flows are passing through the congested node.
9. Informative References
[1] Eardley, P., "Pre-Congestion Notification Architecture",
draft-eardley-pcn-architecture-00 (work in progress),
June 2007.
[2] Babiarz, J., "Three State PCN Marking",
draft-babiarz-pcn-3sm-00 (work in progress), June 2007.
Chan & Karagiannis Expires January 3, 2008 [Page 32]
Internet-Draft Document July 2007
[3] Charny, A., "Pre-Congestion Notification Using Single Marking
for Admission and Termination",
draft-charny-pcn-single-marking-02 (work in progress),
July 2007.
[4] Westberg, L., "LC-PCN - The Load Control PCN solution",
draft-westberg-pcn-load-control-00 (work in progress),
May 2007.
[5] Briscoe, B., "Pre-Congestion Notification marking",
draft-briscoe-tsvwg-cl-phb-03 (work in progress), October 2006.
[6] Baker, F. and J. Polk, "MLEF Without Capacity Admission Does
Not Satisfy MLPP Requirements",
draft-ietf-tsvwg-mlef-concerns-00 (work in progress),
February 2005.
[7] Braden, B., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[8] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski,
J., and L. Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[10] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[12] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[13] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[14] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
Felstaine, "A Framework for Integrated Services Operation over
Diffserv Networks", RFC 2998, November 2000.
Chan & Karagiannis Expires January 3, 2008 [Page 33]
Internet-Draft Document July 2007
[15] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[16] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J.,
Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
March 2002.
[17] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
Ramakrishnan, "Supplemental Information for the New Definition
of the EF PHB (Expedited Forwarding Per-Hop Behavior)",
RFC 3247, March 2002.
[18] Leinen, S., "Evaluation of Candidate Protocols for IP Flow
Information Export (IPFIX)", RFC 3955, October 2004.
[19] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines
for DiffServ Service Classes", RFC 4594, August 2006.
[20] Floyd, S., "Specifying Alternate Semantics for the Explicit
Congestion Notification (ECN) Field", BCP 124, RFC 4774,
November 2006.
[21] "Supporting Real-Time Applications in an Integrated Services
Packet Network: Architecture and Mechanisms", Proceedings of
SIGCOMM '92 at Baltimore MD, August 1992.
[22] "Multilevel Precedence and Pre-emption Service (MLPP)", ITU-T
Recommendation I.255.3, 1990.
[23] "Economics and Scalability of QoS Solutions", BT Technology
Journal Vol 23 No 2, April 2005.
Authors' Addresses
Kwok Ho Chan
Nortel
600 Technology Park Drive
Billerica, MA 01821
USA
Email: khchan@nortel.com
Chan & Karagiannis Expires January 3, 2008 [Page 34]
Internet-Draft Document July 2007
Georgios Karagiannis
University of Twente
P.O. Box 217
7500 AE Enschede,
The Netherlands
Email: g.karagiannis@ewi.utwente.nl
Chan & Karagiannis Expires January 3, 2008 [Page 35]
Internet-Draft Document July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Chan & Karagiannis Expires January 3, 2008 [Page 36]
| PAFTECH AB 2003-2026 | 2026-04-22 21:36:47 |