PCN Working Group                               Philip. Eardley (Editor)
Internet-Draft                                                        BT
Intended status: Standards Track                         October 2, 2008
Expires: April 5, 2009


                     Marking behaviour of PCN-nodes
                  draft-ietf-pcn-marking-behaviour-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 April 5, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document standardises the two marking behaviours of PCN-nodes:
   threshold marking and excess traffic marking.  Threshold marking
   marks all PCN-packets if the PCN traffic rate is greater than a first
   configured rate.  Excess traffic marking marks a proportion of PCN-
   packets, such that the amount marked equals the traffic rate in
   excess of a second configured rate.





Eardley (Editor)          Expires April 5, 2009                 [Page 1]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Specified PCN-marking behaviour  . . . . . . . . . . . . . . .  4
     2.1.  Behaviour aggregate classification function  . . . . . . .  5
     2.2.  Traffic conditioning function  . . . . . . . . . . . . . .  5
     2.3.  Threshold meter function . . . . . . . . . . . . . . . . .  5
     2.4.  Excess traffic meter function  . . . . . . . . . . . . . .  6
     2.5.  Marking function . . . . . . . . . . . . . . . . . . . . .  6
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Changes to -00 . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Authors  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Example algorithms  . . . . . . . . . . . . . . . . . 10
     A.1.  Threshold metering and marking . . . . . . . . . . . . . . 11
     A.2.  Excess traffic metering and marking  . . . . . . . . . . . 12
   Appendix B.  Implementation notes  . . . . . . . . . . . . . . . . 13
     B.1.  Competing-non-PCN-traffic  . . . . . . . . . . . . . . . . 13
     B.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     B.3.  Behaviour aggregate classification . . . . . . . . . . . . 14
     B.4.  Traffic conditioning . . . . . . . . . . . . . . . . . . . 15
     B.5.  Threshold metering . . . . . . . . . . . . . . . . . . . . 16
     B.6.  Excess traffic metering  . . . . . . . . . . . . . . . . . 17
     B.7.  Marking  . . . . . . . . . . . . . . . . . . . . . . . . . 18
   Appendix C.  Per-domain Behaviour  . . . . . . . . . . . . . . . . 18
     C.1.  (from Introduction)  . . . . . . . . . . . . . . . . . . . 19
     C.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     C.3.  Classify . . . . . . . . . . . . . . . . . . . . . . . . . 20
     C.4.  Colour . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     C.5.  Traffic conditioning . . . . . . . . . . . . . . . . . . . 20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22






Eardley (Editor)          Expires April 5, 2009                 [Page 2]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


1.  Introduction

   This document standardises the two marking behaviours of PCN-nodes.
   Their aim is to enable PCN-nodes to give an "early warning" of
   potential congestion before there is any significant build-up of PCN-
   packets in their queues.  In summary, their objectives are:

   o  threshold marking: its objective is to mark all PCN-packets (with
      a "threshold-mark") whenever the rate of PCN-packets is greater
      than some configured rate ("PCN-threshold-rate");

   o  excess traffic marking: whenever the rate of PCN-packets is
      greater than some configured rate ("PCN-excess-rate"), its
      objective is to mark PCN-packets (with an "excess-traffic-mark")
      at a rate equal to the difference between the bit rate of PCN-
      packets and the PCN-excess-rate.

   [I-D.ietf-pcn-architecture] describes a general architecture for how,
   in a particular DiffServ domain, PCN-boundary-nodes convert these
   PCN-markings into decisions about flow admission and flow
   termination.  Other documents describe the wider per-domain behaviour
   and how the PCN-markings are encoded in packet headers.  PCN encoding
   uses a combination of the DSCP field and ECN field in the IP header
   to indicate that a packet is a PCN-packet and whether it is PCN-
   marked.  The baseline encoding [I-D.ietf-pcn-baseline-encoding]
   standardises two encoding states (PCN-marked and not PCN-marked),
   whilst other documents (eg [I-D.moncaster-pcn-3-state-encoding])
   define extended schemes with three encoding states (PCN-threshold-
   marked, PCN-excess-traffic-marked, not PCN-marked).  [RFC3168]
   defines a broadly RED-like default congestion marking behaviour, but
   allows alternatives to be defined; this document defines such an
   alternative.

   Section 2 below specifies the functions involved, which in outline
   (see Figure 1) are:

   o  Behaviour aggregate classification: decide whether an incoming
      packet is a PCN-packet or not.

   o  Condition: drop packets if the link is overloaded.

   o  Threshold meter: determine whether the rate of PCN-packets is
      greater than the configured PCN-threshold-rate.  The measurement
      is made as an aggregate of all PCN-packets, and not per flow.

   o  Excess traffic meter: measure by how much the rate of PCN-packets
      is greater than the configured PCN-excess-rate.  The measurement
      is made as an aggregate of all PCN-packets, and not per flow.



Eardley (Editor)          Expires April 5, 2009                 [Page 3]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


   o  PCN-mark: actually mark the PCN-packets, if the meter functions
      indicate to do so.


                                       +---------+   Result
                                    +->|Threshold|-------+
                                    |  |  Meter  |       |
                                    |  +---------+       V
         +---------+   +- - - - -+  |                 +------+
         |   BA    |   |         |  |                 |      |    Marked
Packet =>|Classify |==>|Condition|==?================>|Marker|==> Packet
Stream   |         |   |         |  |                 |      |    Stream
         +---------+   +- - - - -+  |                 +------+
                                    |  +---------+       ^
                                    |  | Excess  |       |
                                    +->| Traffic |-------+
                                       |  Meter  |   Result
                                       +---------+

   Figure 1: Schematic of functions for PCN-marking

1.1.  Terminology

   In addition to the terminology defined in [I-D.ietf-pcn-architecture]
   and [RFC2474] , the following terms are defined:

   o  Competing-non-PCN-packet: a non PCN-packet that competes for the
      same capacity as PCN-traffic.  "Capacity" means the forwarding
      bandwidth on a link; "competes" means that competing-non-PCN-
      packets will delay PCN-packets in the queue for the link.
      Competing-non-PCN-packets MUST NOT be PCN-marked (ie only PCN-
      packets can be PCN-marked).  Note: In general it is not advised to
      have any competing-non-PCN-traffic.

   o  Metered-packet: a packet that is metered by the metering functions
      specified below (with the minor exception noted below in Section
      2.5).  A PCN-packet MUST be treated as a metered-packet.  A
      competing-non-PCN-packet MAY be treated as a metered-packet.


2.  Specified PCN-marking behaviour

   This section specifies the PCN-marking behaviour.  The descriptions
   are functional and are not intended to restrict the implementation..
   The Informative Appendixes supplement it.






Eardley (Editor)          Expires April 5, 2009                 [Page 4]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


2.1.  Behaviour aggregate classification function

   A PCN-node MUST classify a packet as a PCN-packet if the value of its
   DSCP and ECN fields correspond to a PCN-enabled codepoint, as defined
   in the encoding scheme applicable to the PCN-domain.  Otherwise the
   packet MUST NOT be classified as a PCN-packet.

   A PCN-node MUST classify a packet as a competing-non-PCN-packet if it
   is not a PCN-packet and it competes for the same capacity as PCN-
   traffic.  "Capacity" means the forwarding bandwidth on a link;
   "competes" means that competing-non-PCN-packets will delay PCN-
   packets in the queue for the link.

2.2.  Traffic conditioning function

   Note: if the PCN-node's queue overflows then naturally packets are
   dropped; traffic conditioning is action additional to this.

   On all links in the PCN-domain, traffic conditioning MAY be done by:

   o  metering all metered-packets to determine if the level of metered-
      traffic is sufficiently high to overload the PCN behaviour
      aggregate.  (According to [RFC2475] metering is "the process of
      measuring the temporal properties (eg rate) of a traffic stream".)

   o  if the level of metered-traffic is sufficiently high, then drop
      metered-packets.

   If the PCN-node drops PCN-packets then:

   o  PCN-packets that arrive at the PCN-node already excess-traffic-
      marked SHOULD be preferentially dropped;

   o  the PCN-node's Excess traffic Meter SHOULD NOT meter the PCN-
      packets that it drops.

2.3.  Threshold meter function

   A PCN-node MUST implement a Threshold Meter that has behaviour
   functionally equivalent to the following.

   The meter acts like a token bucket, which is sized in bits and has a
   configured bit rate, termed PCN-threshold-rate.  The amount of tokens
   in the token bucket is termed TBthreshold.fill.  Tokens are added at
   the PCN-threshold-rate, to a maximum value TBthreshold.max.  Tokens
   are removed equal to the size in bits of the metered-packet, to a
   minimum TBthreshold.fill=0.




Eardley (Editor)          Expires April 5, 2009                 [Page 5]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


   The token bucket has a configured intermediate depth, termed
   TBthreshold.threshold.  If TBthreshold.fill < TBthreshold.threshold,
   then the meter indicates to the Marking function that the packet is
   to be threshold-marked; otherwise it does not.

2.4.  Excess traffic meter function

   A packet SHOULD NOT be metered (by this excess traffic meter
   function) in the following two cases:

   o  If the packet is already excess-traffic-marked on arrival at the
      PCN-node;

   o  If this PCN-node drops the packet.

   Otherwise it is metered by the Excess traffic Meter.

   A PCN-node MUST implement an Excess traffic Meter that has behaviour
   functionally equivalent to the following.

   The meter acts like a token bucket, which is sized in bits and has a
   configured bit rate, termed PCN-excess-rate.  The amount of tokens in
   the token bucket is termed TBexcess.fill.  Tokens are added at the
   PCN-excess-rate, to a maximum value TBexcess.max.  Tokens are removed
   equal to the size in bits of the metered-packet, to a minimum
   TBexcess-fill=0.  The PCN-excess-rate is greater than (or equal to)
   the PCN-threshold-rate.

   If the token bucket is empty (TBexcess.fill = 0), then the meter
   indicates to the Marking function that the packet is to be excess-
   traffic-marked.

   In addition to the above, if the token bucket is within an MTU of
   being empty, then the meter SHOULD indicate to the Marking function
   that the packet is to be excess-traffic-marked; MTU means the maximum
   size of PCN-packets on the link.  Otherwise the meter MUST NOT
   indicate marking.

2.5.  Marking function

   A PCN-node MUST NOT:

   o  PCN-mark a packet that is not a PCN-packet;

   o  change a non PCN-packet into a PCN-packet;

   o  change a PCN-packet into a non PCN-packet.




Eardley (Editor)          Expires April 5, 2009                 [Page 6]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


   A PCN-packet MUST be marked to reflect the metering results by
   setting its encoding state appropriately, as specified below.  The
   encoding states are defined values of the DSCP and ECN fields, as
   specified in the appropriate encoding document.

   There are three possibilities, depending on how many encoding states
   are available:

   o  if three encoding states are available (one for threshold-marked,
      one for excess-traffic-marked and one for "not PCN-marked") then:

      *  the encoding state of a packet that has already been excess-
         traffic-marked is not altered, whatever the meters indicate;

      *  Otherwise:

         +  if both meters indicate marking, then the packet is excess-
            traffic-marked;

         +  if the threshold meter indicates marking and the excess
            traffic meter doesn't, then threshold-marking is applied;

         +  if the excess traffic meter indicates marking and the
            threshold traffic meter doesn't, then excess-traffic-marking
            is applied;

         +  if neither meter indicates marking, then the packet's
            encoding state is not altered.

   o  if two encoding states are available (one for threshold-marked and
      one for "not PCN-marked") then:

      *  if the Threshold Meter indicates marking, then the packet is
         threshold-marked;

      *  otherwise the packet's encoding state is not altered.

   o  if two encoding states are available (one for excess-traffic-
      marked and one for "not PCN-marked") then:

      *  if the Excess traffic Meter indicates marking, then the packet
         is excess-traffic-marked;

      *  otherwise the packet's encoding state is not altered.







Eardley (Editor)          Expires April 5, 2009                 [Page 7]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


3.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


4.  Security Considerations

   See [I-D.ietf-pcn-architecture]


5.  Acknowledgements

   Michael Menth, Joe Babiarz, Anna Charny reviewed a preliminary
   version of the draft-eardley-pcn-marking-behaviour-00 draft.

   Thanks to those who've made comments on this draft: Michael Menth,
   Joe Babiarz, Anna Charny, Ruediger Geib, Wei Gengyu, Fortune Huang,
   Bob Briscoe, Toby Moncaster, Christian Hublet, Ingemar Johansson, Ken
   Carlberg, Georgios Karagiannis.

   All the work by many people in the PCN WG.


6.  Changes

6.1.  Changes to -00

   First version of WG draft, derived from
   draft-eardley-pcn-marking-behaviour-01, with the following changes:

   o  Removed material concerning per domain behaviour and PCN-boundary-
      node operation (temporarily archived to Appendix C)

   o  Removed mention of downgrading as an option for per-hop traffic
      conditioning.  In fact, downgrading is no longer allowed because S
      2.6 now says "A PCN-node MUST NOT ...change a PCN-packet into a
      non PCN-packet".

   o  Traffic conditioning is now a MAY.  Since in general flow
      termination (not traffic conditioning) is PCN's method for
      handling problems of too much traffic.

   o  Metered-packets: competing-non-PCN-packets now MAY be metered.
      Since it is recommended that the operator doesn't allow any
      competing-non-PCN-traffic, and (if there is) there are potentially



Eardley (Editor)          Expires April 5, 2009                 [Page 8]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


      other ways of coping.

   o  No changes (outside traffic conditioning & metering of competing-
      non-PCN-traffic) to the Normative sections of the draft.

   o  Appendix B.1 added about competing-non-PCN-traffic.  Recommended
      that there is no such traffic, but guidance given if there is.


7.  Authors

   Many people need to be added.


8.  References

8.1.  Normative References

   [I-D.ietf-pcn-architecture]
              Eardley, P., "Pre-Congestion Notification (PCN)
              Architecture", draft-ietf-pcn-architecture-07 (work in
              progress), September 2008.

   [I-D.ietf-pcn-baseline-encoding]
              Moncaster, T., Briscoe, B., and M. Menth, "Baseline
              Encoding and Transport of Pre-Congestion Information",
              draft-ietf-pcn-baseline-encoding-00 (work in progress),
              September 2008.

   [RFC2474]  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.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

8.2.  Informative References

   [I-D.briscoe-tsvwg-byte-pkt-mark]
              Briscoe, B., "Byte and Packet Congestion Notification",
              draft-briscoe-tsvwg-byte-pkt-mark-02 (work in progress),
              February 2008.

   [I-D.briscoe-tsvwg-cl-architecture]
              Briscoe, B., "An edge-to-edge Deployment Model for Pre-
              Congestion Notification: Admission  Control over a



Eardley (Editor)          Expires April 5, 2009                 [Page 9]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


              DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04
              (work in progress), October 2006.

   [I-D.charny-pcn-comparison]
              Charny, A., "Comparison of Proposed PCN Approaches",
              draft-charny-pcn-comparison-00 (work in progress),
              November 2007.

   [I-D.ietf-tsvwg-admitted-realtime-dscp]
              Baker, F., Polk, J., and M. Dolly, "DSCPs for Capacity-
              Admitted Traffic",
              draft-ietf-tsvwg-admitted-realtime-dscp-04 (work in
              progress), February 2008.

   [I-D.moncaster-pcn-3-state-encoding]
              Moncaster, T., Briscoe, B., and M. Menth, "A three state
              extended PCN encoding scheme",
              draft-moncaster-pcn-3-state-encoding-00 (work in
              progress), June 2008.

   [Menth]    "Menth", 2008, <http://www3.informatik.uni-wuerzburg.de/
              staff/menth/Publications/Menth08-PCN-Comparison.pdf>.

   [RFC1633]  Braden, B., Clark, D., and S. Shenker, "Integrated
              Services in the Internet Architecture: an Overview",
              RFC 1633, June 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3086]  Nichols, K. and B. Carpenter, "Definition of
              Differentiated Services Per Domain Behaviors and Rules for
              their Specification", RFC 3086, April 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC5129]  Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
              Marking in MPLS", RFC 5129, January 2008.


Appendix A.  Example algorithms

   Note: This Appendix is informative, not normative.  It is an example
   of algorithms that implement Section 2 and is based on
   [I-D.charny-pcn-comparison] and [Menth].




Eardley (Editor)          Expires April 5, 2009                [Page 10]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


   There is no attempt to optimise the algorithms.  It implements the
   metering and marking functions together.  It is assumed that three
   encoding states are available (one for threshold-marked, one for
   excess-traffic-marked and one for "not PCN-marked").  It is assumed
   that all metered-packets are PCN-packets and that the link is never
   overloaded.

A.1.  Threshold metering and marking

   A token bucket with the following parameters:

   o  TBthreshold.PCN-threshold-rate: token rate of token bucket (bits/
      second)

   o  TBthreshold.max: depth of token bucket (bits)

   o  TBthreshold.threshold: marking threshold of token bucket (bits)

   o  TBthreshold.lastUpdate: time the token bucket was last updated
      (seconds)

   o  TBthreshold.fill: amount of tokens in token bucket (bits)

   A PCN-packet has the following parameters:

   o  packet.size: the size of the PCN-packet (bits)

   o  packet.mark: the PCN encoding state of the packet

   In addition there are the parameters:

   o  now: the current time (seconds)

   The following steps are performed when a PCN-packet arrives on a
   link:

   o  TBthreshold.fill = min(TBthreshold.max, TBthreshold.fill + (now -
      TBthreshold.lastUpdate) * TBthreshold.PCN-threshold-rate); // add
      tokens to token bucket

   o  TBthreshold.fill = max(0, TBthreshold.fill - packet.size); //
      remove tokens from token bucket

   o  if ((TBthreshold.fill < TBthreshold.threshold) AND (packet.mark !=
      excess-traffic-marked)) then packet.mark = threshold-marked; // do
      threshold marking, but don't re-mark packets that are already
      excess-traffic-marked




Eardley (Editor)          Expires April 5, 2009                [Page 11]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


   o  TBthreshold.lastUpdate = now

A.2.  Excess traffic metering and marking

   A token bucket with the following parameters:

   o  TBexcess.PCN-excess-rate: token rate of token bucket (bits/second)

   o  TBexcess.max: depth of TB in token bucket (bits)

   o  TBexcess.lastUpdate: time the token bucket was last updated
      (seconds)

   o  TBexcess.fill: amount of tokens in token bucket (bits)

   A PCN-packet has the following parameters:

   o  packet.size: the size of the PCN-packet (bits)

   o  packet.mark: the PCN encoding state of the packet

   In addition there are the parameters:

   o  now: the current time (seconds)

   o  MTU: the maximum transfer unit of the link (or the known maximum
      size of PCN-packets on the link) (bits)

   The following steps are performed when a PCN-packet arrives on a
   link:

   o  TBexcess.fill = min(TBexcess.max, TBexcess.fill + (now -
      TBexcess.lastUpdate) * TBexcess.PCN-excess-rate); // add tokens to
      token bucket

   o  if (packet.mark != excess-traffic-marked) then TBexcess.fill =
      max(0, TBexcess.fill - packet.size); // remove tokens from token
      bucket, but do not meter packets that are already excess-traffic-
      marked

   o  if (TBexcess.fill < MTU) then packet.mark = excess-traffic-marked;
      // do (packet size independent) excess traffic marking

   o  TBthreshold.lastUpdate = now







Eardley (Editor)          Expires April 5, 2009                [Page 12]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


Appendix B.  Implementation notes

   Note: This Appendix is informative, not normative.  It comments on
   Section 2.

B.1.  Competing-non-PCN-traffic

   In general it is not advised to have any competing-non-PCN-traffic,
   essentially because the unpredictable amount of competing-non-PCN-
   traffic makes the PCN mechanisms less accurate and so reduces PCN's
   ability to protect the QoS of admitted PCN-flows
   [I-D.ietf-pcn-architecture].  But if there is competing-non-PCN-
   traffic, then there needs to be:

   1.  a mechanism to limit it, for example:

       *  limiting the rate at competing-non-PCN-traffic can be
          forwarded on each link in the PCN-domain.  One method for
          achieving this is to queue competing-non-PCN-packets
          separately from PCN-packets, and to limit the scheduling rate
          of the former.  Another method is to police (traffic
          condition) the competing-non-PCN-traffic on each link, ie drop
          competing-non-PCN-packets in excess of some rate.

       *  policing of competing-non-PCN-traffic at the PCN-ingress-
          nodes.  For example, as in the DiffServ architecture -
          although its static traffic conditioning agreements risk a
          focussed overload of traffic from several PCN-ingress-nodes on
          one link.

       *  design: it is known by design that the level of competing-non-
          PCN-traffic is always very small (perhaps it consists of
          operator control messages only)

   2.  In general PCN's mechanisms should take account of competing-non-
       PCN-traffic (in order to improve the accuracy of the decision
       about whether to admit (or terminate) a PCN-flow), for example
       by:

       *  competing-non-PCN-traffic contributes to the PCN meters (ie
          competing-non-PCN-packets are treated as metered-packets).

       *  each PCN-node reduces, on its links, the PCN-threshold-rate
          and PCN-excess-rate, in order to allow 'headroom' for the
          competing-non-PCN-traffic; also limiting the maximum
          forwarding rate of competing-non-PCN-traffic to be less than
          the 'headroom'.  In this case competing-non-PCN-packets are
          not treated as metered-packets.



Eardley (Editor)          Expires April 5, 2009                [Page 13]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


   It is left up to the operator to decide on appropriate action.
   Traffic conditioning is discussed further in the separate section
   below.

   One specific example of competing-non-PCN-traffic occurs if the PCN-
   compatible Diffserv codepoint is the Voice-admit codepoint, and there
   is voice-admit traffic in the PCN-domain.

   Another example would occur if there was more than one PCN-compatible
   Diffserv codepoint in a PCN-domain.  For instance, suppose there were
   two PCN-BAs treated at different priorities.  Then as far as the
   lower priority PCN-BA is concerned, the higher priority PCN-traffic
   needs to be treated as competing-non-PCN-traffic.

B.2.  Scope

   It may be known, eg by the design of the network topology, that some
   links can never be pre-congested (even in unusual circumstances, eg
   after the failure of some links).  There is then no need to deploy
   PCN behaviour on those links.

   The meter and marker can be implemented on the ingoing or outgoing
   interface of a PCN-node.  It may be that existing hardware can
   support only one meter and marker per ingoing interface and one per
   outgoing interface.  Then for instance threshold metering and marking
   could be run on all the ingoing interfaces and excess traffic
   metering and marking on all the outgoing interfaces; note that the
   same choice must be made for all the links in a PCN-domain to ensure
   that the two metering behaviours are applied exactly once for all the
   links.

   Note that even if there are only two encoding states, it is still
   required that both the meters are implemented, in order to ease
   compatibility between equipment and remove a configuration option and
   associated complexity.  Hardware with limited availability of token
   buckets could be configured to run only one of the meters, but it
   must be possible to enable either meter.  Although this scenario
   means that the Marking function ignores indications from one of the
   meters, they might be logged or acted upon in some other way, for
   example by the management system or an explicit signalling protocol;
   such considerations are out of scope of PCN.

B.3.  Behaviour aggregate classification

   Configuration of PCN-nodes will define what values of the DSCP and
   ECN fields indicate a PCN-packet in a particular PCN-domain.

   Configuration will also define what values of the DSCP and ECN fields



Eardley (Editor)          Expires April 5, 2009                [Page 14]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


   indicate a competing-non-PCN-packet in a particular PCN-domain.

B.4.  Traffic conditioning

   If there is no competing-non-PCN-traffic, then it is not expected
   that traffic conditioning is needed, since PCN's flow admission and
   termination mechanisms limit the amount of PCN-traffic.  Even so,
   traffic conditioning still might be implemented as a back stop
   against misconfiguration of the PCN-domain, for instance.

   The objective of traffic conditioning is to minimise the queueing
   delay suffered by metered-traffic at a PCN-node, since PCN-traffic
   (and perhaps competing-non-PCN-traffic) is expected to be inelastic
   traffic generated by real time applications.  In practice it would be
   defined as exceeding a specific traffic profile, typically based on a
   token bucket.  The details will depend on how the router's
   implementation handles the two sorts of traffic
   [I-D.ietf-tsvwg-admitted-realtime-dscp]:

   o  a common queue for PCN-traffic and competing-non-PCN-traffic, and
      a traffic conditioner for the competing-non-PCN-traffic;

   o  separate queues.  In this case the amount of competing-non-PCN-
      traffic can be limited by limiting the rate at which the scheduler
      (for the competing-non-PCN-traffic) forwards packets.

   The traffic conditioning action is to drop packets.  Downgrading of
   packets to a lower priority BA is left as a theoretical possibility
   (beware of packet mis-ordering).  Shaping ("the process of delaying
   packets" [RFC2475]) is not suitable here as the traffic is expected
   to come from real time applications.  In general it is reasonable for
   competing-non-PCN-traffic to get harsher treatment than PCN-traffic
   (ie competing-non-PCN-packets are preferentially dropped), because
   PCN's flow admission and termination mechanisms are stronger than the
   mechanisms that are likely to be applied to the competing-non-PCN-
   traffic.  The PCN mechanisms also mean that a policer should not be
   needed for the PCN-traffic.

   Preferential dropping of excess-traffic-marked packets: Section 2.3
   specifies: "If the PCN-node drops PCN-packets then ...  PCN-packets
   that arrive at the PCN-node already excess-traffic-marked SHOULD be
   preferentially dropped".  This avoids over-termination, with the
   CL/SM edge behaviour, in the event of multiple bottlenecks in the
   PCN-domain [I-D.charny-pcn-comparison].

   Exactly what "preferentially dropped" means is left to the
   implementation.  It is also left to the implementation what to do if
   there are no excess-traffic-marked PCN-packets available at a



Eardley (Editor)          Expires April 5, 2009                [Page 15]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


   particular instant.

   Section 2.2 also specifies: "PCN-packets that are dropped
   (downgraded) SHOULD NOT be metered by the Excess traffic Meter."
   This avoids over-termination, with the CL/SM edge behaviour, in the
   event of multiple bottlenecks [I-D.charny-pcn-comparison].
   Effectively it means that traffic conditioning should be done before
   the meter functions - which is natural.

B.5.  Threshold metering

   The description is in terms of a 'token bucket with threshold' (which
   [I-D.briscoe-tsvwg-cl-architecture] views as a virtual queue).
   However the implementation is not standardised.

   Section 2.3 defines: "If TBthreshold.fill < TBthreshold.threshold,
   then the meter indicates to the Marking function that the packet is
   to be threshold-marked; otherwise it does not."  Note that the PCN-
   packet (that causes the token bucket to cross TBthreshold.threshold)
   is marked without explicit additional bias for the packet's size.

   The behaviour must be functionally equivalent to the description
   above.  "Functionally equivalent" means the observable 'black box'
   behaviour is the same or very similar.  It is intended to allow
   implementation freedom over matters such as:

   o  whether tokens are added to the token bucket at regular time
      intervals or only when a packet is processed

   o  whether the new token bucket depth is calculated before or after
      it is decided whether to mark the packet.  The effect of this is
      simply to shift the sequence of marks by one packet.

   o  when the token bucket is very nearly empty and a packet arrives
      larger than TBthreshold.fill, then the precise change in
      TBthreshold.fill is up to the implementation.  A behaviour is
      functionally equivalent if either precisely the same set of
      packets is marked, or if the set is shifted by one packet.  For
      instance, the following should all be considered as "functionally
      equivalent":

      *  set TBthreshold.fill = 0 and indicate threshold-mark to the
         Marking function.

      *  check whether TBthreshold.fill < TBthreshold.threshold and if
         it is then indicate threshold-mark to the Marking function;
         then set TBthreshold.fill = 0.




Eardley (Editor)          Expires April 5, 2009                [Page 16]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


      *  leave TBthreshold.fill unaltered and indicate threshold-mark to
         the Marking function.

   o  similarly, when the token bucket is very nearly full and a packet
      arrives large than (TBthreshold.max - TBthreshold.fill), then the
      precise change in TBthreshold.fill is up to the implementation.

   o  Note that all packets, even if already marked, are metered by the
      threshold meter function (unlike the excess traffic meter function
      - see below) - because all packets should contribute to the
      decision whether there is room for a new flow.

B.6.  Excess traffic metering

   The description is in terms of a token bucket, however the
   implementation is not standardised.

   As in Section B.3, "functionally equivalent" allows some
   implementation flexibility when the token bucket is very nearly empty
   or very nearly full.

   Packet size independent marking is specified as a SHOULD in Section
   2.4 ( "If the token bucket is within an MTU of being empty, then the
   meter SHOULD indicate to the Marking function that the packet is to
   be excess-traffic-marked; MTU means the maximum size of PCN-packets
   on the link.")  Without it, large packets are more likely to be
   excess-traffic-marked than small packets and this means that, with
   some edge behaviours, flows with large packets are more likely to be
   terminated than flows with small packets
   [I-D.briscoe-tsvwg-byte-pkt-mark] [Menth].

   Section 2.4 specifies: "A packet SHOULD NOT be metered (by this
   excess traffic meter function) ...  If the packet is already excess-
   traffic-marked".  This avoids over-termination (with some edge
   behaviours) in the event that the PCN-traffic passes through multiple
   bottlenecks in the PCN-domain [I-D.charny-pcn-comparison].  Note that
   an implementation could determine whether the packet is already
   excess-traffic-marked as an integral part of its Classification
   function.

   Section 2.4 specifies: "A packet SHOULD NOT be metered (by this
   excess traffic meter function) ...  If this PCN-node drops
   (downgrades) the packet because the link is overloaded."  This avoids
   over-termination [Menth].  (A similar statement could also be made
   for the threshold meter function, but is irrelevant, as a link that
   is overloaded will already be substantially pre-congested and hence
   PCN-marking all packets.)




Eardley (Editor)          Expires April 5, 2009                [Page 17]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


   Note that TBexcess.max is independent of TBthreshold.max;
   TBexcess.fill is independent of TBthreshold.fill (except in that a
   packet changes both); and the two configured rates, PCN-excess-rate
   and PCN-threshold-rate are independent (except that PCN-excess-rate
   >= PCN-threshold-rate).

B.7.  Marking

   Section 2.5 defines: "A PCN-node MUST NOT ...change a PCN-packet into
   a non PCN-packet".  This means that a PCN-node MUST NOT traffic
   condition by downgrading a PCN-packet into a lower priority DiffServ
   BA.  The bullet needs to be modified if the WG decides to allow such
   traffic conditioning.

   Section 2.5 defines: "A PCN-node MUST NOT ...PCN-mark a packet that
   is not a PCN-packet".  This means that in the scenario where
   competing-non-PCN-packets are treated as metered-packets, a meter may
   indicate a packet is to be PCN-marked, but the Marking function knows
   it cannot be marked.  It is left open to the implementation exactly
   what to do in this case; one simple possibility is to mark the next
   PCN-packet.  Note that unless the PCN-packets are a large fraction of
   all the metered-packets then the PCN mechanisms may not work well.

   Although the metering functions are described separately from the
   Marking function, they can be implemented in an integrated fashion.

   In some environments encoding states may be scarce, for example MPLS
   [RFC5129], and then it may be preferable to have only two encoding
   states, as in the baseline encoding [I-D.ietf-pcn-baseline-encoding].
   In other environments it will be possible to use one of the extension
   encodings that specify three encoding states.

   Section 2.5 states: "if three encoding states are available ... if
   the threshold meter indicates marking and the excess traffic meter
   doesn't, then threshold-marking is applied; if the excess traffic
   meter indicates marking and the threshold traffic meter doesn't, then
   excess-traffic-marking is applied".  The latter case seems infeasible
   but is possible for a short time - because the meters might react at
   different speeds when the traffic rate changes.


Appendix C.  Per-domain Behaviour

   Note: This Appendix is informative, and to be deleted in next
   version.  It simply archives material from the previous draft which
   concerns PCN-boundary-node behaviour and/or per-domain behaviour
   [RFC3086].




Eardley (Editor)          Expires April 5, 2009                [Page 18]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


C.1.  (from Introduction)

   [ietf-pcn-architecture] describes a general architecture for flow
   admission and termination based on pre-congestion information in
   order to protect the quality of service of established inelastic
   flows within a single DiffServ domain.  The pre-congestion
   information consists of specific markings of PCN-packets.  The edge
   nodes of the DiffServ domain read these markings and convert them
   into flow admission and termination decisions.

   So in a particular deployment the operator may have three encoding
   states available (so allowing both threshold marking and excess
   traffic marking) or may have only two encoding states (so allowing
   either threshold marking and excess traffic marking).  As described
   in [I-D.ietf-pcn-architecture], flow termination is based on excess
   traffic marked packets, whilst admission control can be based on
   either threshold marked or excess traffic marked packets (the former
   is more accurate, [I-D.charny-pcn-comparison]).  This leads to the
   following four use cases:

   1.  an operator requires both admission control and flow termination,
       and has three encoding states available.  Then admission control
       is triggered from PCN-packets that are threshold-marked, and flow
       termination from PCN-packets that are excess-traffic-marked.

   2.  an operator requires both admission control and flow termination,
       and has only two encoding states available.  Then both admission
       control and flow termination are triggered from PCN-packets that
       are excess-traffic-marked.

   3.  an operator requires only admission control.  Then admission
       control is triggered from PCN-packets that are threshold-marked
       and only two encoding states are needed.  (Flow termination may
       be provided by a non PCN mechanism; this is out of scope.)

   4.  an operator requires only flow termination.  Then flow
       termination is triggered from PCN-packets that are excess-
       traffic-marked and only two encoding states are needed.
       (Admission control may be provided by a non PCN mechanism; this
       is out of scope.)

C.2.  Scope

   The functions defined in the following sub-sections SHOULD be
   implemented on all links in the PCN-domain.

   There are three possibilities regarding encoding states:




Eardley (Editor)          Expires April 5, 2009                [Page 19]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


   o  three encoding states are available,

      *  one for threshold marks,

      *  one for excess rate marks

      *  one for "not PCN-marked";

   o  two encoding states are available,

      *  one for threshold marks

      *  one for "not PCN-marked";

   o  two encoding states are available,

      *  one for excess rate marks

      *  one for "not PCN-marked".

   The same choice of encoding states MUST be used throughout a PCN-
   domain.

C.3.  Classify

   Configuration action defines the values of DSCP & ECN fields
   associated with PCN across the domain.

C.4.  Colour

   PCN-ingress-nodes MUST colour PCN-traffic (if necessary) by altering
   the DSCP and ECN fields to values appropriate for the PCN-domain.

C.5.  Traffic conditioning

   In addition, PCN-ingress-nodes MUST police PCN-traffic by

   [NOTE; discussion in Dublin: make this a SHOULD, as PCN may well be a
   small % traffic and is prioritised]:

   o  metering PCN-packets that are part of a previously admitted PCN-
      flow, to check that it keeps to the agreed rate or flowspec (eg
      [RFC1633] for a microflow, and its NSIS equivalent).

   o  checking that any packets received that demand PCN treatment do
      indeed belong to a previously admitted flow.





Eardley (Editor)          Expires April 5, 2009                [Page 20]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


   o  dropping or downgrading packets that fail the above checks.

   In addition, PCN-ingress-nodes MUST police other-traffic by:

   o  metering other-traffic to check that it meets its traffic
      conditioning agreement, which is the parameters of the traffic
      that will be accepted from a customer.  Typically it is statically
      defined as part of the subscription-time service level agreement,
      as in the DiffServ architecture [RFC2475].

   o  dropping or downgrading packets that fail the above check.

   In addition, an operator MAY measure the amount of traffic entering
   (or leaving) its network for accounting reasons.  Consideration is
   out of scope of this document.


Author's Address

   Philip Eardley
   BT
   Adastral Park, Martlesham Heath
   Ipswich  IP5 3RE
   UK

   Email: philip.eardley@bt.com

























Eardley (Editor)          Expires April 5, 2009                [Page 21]


Internet-Draft       Marking behaviour of PCN-nodes         October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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).





Eardley (Editor)          Expires April 5, 2009                [Page 22]