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]