[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-pcn-cl-edge-behaviour

Internet Engineering Task Force                                A. Charny
Internet-Draft                                             Cisco Systems
Intended status: Informational                                  F. Huang
Expires: September 3, 2009                           Huawei Technologies
                                                                M. Menth
                                                 University of Wuerzburg
                                                          T. Taylor, Ed.
                                                     Huawei Technologies
                                                           March 2, 2009


    PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of
                               Operation
                 draft-taylor-pcn-cl-edge-behaviour-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 September 3, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.



Charny, et al.          Expires September 3, 2009               [Page 1]

Internet-Draft       PCN CL Boundary Node Behaviour           March 2009


Abstract

   Precongestion notification (PCN) is a means for protecting quality of
   service for inelastic traffic admitted to a Diffserv domain.  The
   overall PCN architecture is described in ID.PCNArch.  This memo is
   one of a series describing possible boundary node behaviours for a
   PCN domain.  The behaviour described here is that for three-state
   measurement-based load control, known informally as CL.  The
   requirement for three encoding states means that CL is for
   experimental use only pending further standards action.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Assumed Core Network Behaviour for CL  . . . . . . . . . . . .  4
   3.  Node Behaviours  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Measurement Requirements . . . . . . . . . . . . . . . . .  5
     3.2.  Decision-Making Behaviour  . . . . . . . . . . . . . . . .  6
       3.2.1.  Determining Whether Flow Termination Is Required . . .  6
       3.2.2.  Estimating the Amount of Traffic To Terminate  . . . .  7
       3.2.3.  Flow Admission Decisions . . . . . . . . . . . . . . .  7
   4.  Assumed Signalling Flows . . . . . . . . . . . . . . . . . . .  8
     4.1.  Assumed Signalling To Support Classification . . . . . . .  8
     4.2.  Assumed Signalling Of Measurements . . . . . . . . . . . .  8
   5.  Deployment Considerations  . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Operation With Standalone PCN-Decision-Node . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10














Charny, et al.          Expires September 3, 2009               [Page 2]

Internet-Draft       PCN CL Boundary Node Behaviour           March 2009


1.  Introduction

   Precongestion notification (PCN) is a means for protecting quality of
   service (QoS) for inelastic traffic admitted to a Diffserv domain.
   The overall PCN architecture is described in [ID.PCNArch].  In the
   general case, QoS is protected by restricting admission of PCN-
   traffic to the PCN-domain when precongestion indications are first
   detected.  In the case of catastrophic failures or a sudden increase
   in traffic offered by admitted flows, QoS is protected by terminating
   PCN-flows to the point where traffic falls to a level which appears
   to be supportable in current conditions.  Detection of congestion
   status, the making of admission decisions, and the making of
   termination decisions are all done on the basis of the ingress-
   egress-aggregate as defined in [ID.PCNArch].

   Boundary node behaviours specify how the PCN-ingress-node and PCN-
   egress-node make use of the PCN mechanisms to achieve QoS protection.

1.1.  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 [RFC2119].

1.2.  Terminology

   In addition to the terms defined in [ID.PCNArch], this document uses
   the following terms:

   o  Measurement period - the period of time over which a measurement
      or set of measurements is accumulated.

   o  PCN-sent-traffic - the total PCN-traffic, measured in octets per
      period, that is admitted to a given ingress-egress-aggregate by
      the PCN-ingress-node.

   o  Edge-to-edge supportable rate of PCN-traffic - the maximum rate of
      PCN-traffic that can be carried through the PCN network for a
      given ingress-egress-aggregate at a given moment of time.
      Estimated by the rate of PCN-traffic received at the egress node
      without excess-traffic-marking during measurement periods in which
      excess-traffic-marked packets are received.

   o  PCN-decision-node - the node that makes admission and flow
      termination decisions based on an evaluation of the traffic
      measurements for a given ingress-egress aggregate.  The main body
      of this document assumes that the PCN-decision-node is the same as
      the PCN-ingress-node.  Appendix A considers the alternative where



Charny, et al.          Expires September 3, 2009               [Page 3]

Internet-Draft       PCN CL Boundary Node Behaviour           March 2009


      the PCN-decision-node is a separate entity.

1.3.  Summary

   The remainder of this document describes the assumed core node
   behaviour for the CL mode, the behaviour of the ingress and egress
   nodes, the signalling requirements between the nodes, and the
   deployment considerations specific to the CL mode.  As mentioned
   already, Appendix A describes the operation of CL mode when the PCN-
   decision-node is separate from the PCN-ingress-node.


2.  Assumed Core Network Behaviour for CL

   This section describes the assumed behaviour for nodes of the PCN-
   domain when acting in their role as PCN-interior-nodes.  The CL mode
   of operation assumes that:

   o  encoding of PCN status within individual packets is based on
      [ID.PCN-baseline], extended to provide a third encoding state.
      Possible extensions for this purpose are documented in
      [ID.PCN3state] or alternatively [ID.PCN3in1];

   o  the domain satisfies the conditions specified in the applicable
      extension document;

   o  each link has been configured with a PCN-threshold-rate having a
      value equal to the PCN-admissible-rate for the link;

   o  each link has been configured with a PCN-excess-rate having a
      value equal to the PCN-supportable-rate for the link;

   o  PCN-interior-nodes perform threshold-marking and excess-traffic-
      marking of packets according to the rules specified in
      [ID.PCN-marking], and any additional rules specified in the
      applicable extension document;

   According to [ID.PCN-baseline], the extension documents should
   specify the allowable transitions between marking states.  However,
   to be absolutely clear, these allowable transitions are specified
   here.  At any interior node, the only permitted transitions are
   these:

   o  a PCN packet which is not marked (NM) MAY be threshold-marked
      (ThM) or excess-traffic-marked (ETM);

   o  a PCN packet which is threshold-marked (ThM) MAY be excess-
      traffic-marked (ETM).



Charny, et al.          Expires September 3, 2009               [Page 4]

Internet-Draft       PCN CL Boundary Node Behaviour           March 2009


   An interior node MUST NOT re-mark a packet from PCN to non-PCN, or
   vice versa.


3.  Node Behaviours

3.1.  Measurement Requirements

   [We need to think about the units.  Will octet counts exceed 2 ** 32
   per second?]

   For each ingress-egress-aggregate, the egress node MUST continuously
   measure the following quantities:

   o  NM-count: number of octets of PCN-traffic contained in received
      packets which are neither threshold-marked nor excess-traffic-
      marked;

   o  ThM-count: number of octets of PCN-traffic contained in received
      packets which are threshold-marked;

   o  ETM-count: number of octets of PCN-traffic contained in received
      packets which are excess-traffic-marked.

   The egress node MUST capture its observations as octet counts per
   measurement period but convert them to rates (octets per second) for
   reporting purposes.  The egress node MUST report these quantities to
   the ingress node as soon as possible after the end of the measurement
   period.  The egress node MUST also include the duration D of the
   measurement period in milliseconds in this report.

   To avoid measurement bias, successive measurement periods MUST be of
   the same duration, and the end of one measurement period MUST be the
   beginning of the next one, independently of current flow conditions.
   It is RECOMMENDED that the length of the measurement period lie
   between 100 and 500 ms, to provide a reasonable tradeoff between
   signalling demands on the network and the time taken to react to
   impending congestion.

      Note that, according to the logic presented in the next section,
      the choice of measurement period duration also determines the
      increment of time during which a policy of "admit" or "block"
      persists for new flows offered to the ingress-egress-aggregate.

   The ingress node MUST determine the current rate of PCN-sent-traffic
   (octets per second) through measurement, but only when it receives a
   report for a given ingress-egress-aggregate that contains a non-zero
   count of excess-marked packets.  It MAY do this by measuring



Charny, et al.          Expires September 3, 2009               [Page 5]

Internet-Draft       PCN CL Boundary Node Behaviour           March 2009


   continuously and recording observations per measurement period in the
   same way as the egress node, then selecting the rate calculated for
   the most recent measurement period.  See Section 3.2.2 for how this
   quantity is used to calculate the amount of traffic to be terminated.

3.2.  Decision-Making Behaviour

   This section describes the behaviour required to make decisions on
   when to admit flows, when to block them, and when to terminate flows
   already admitted, for a given ingress-egress-aggregate.  This is the
   role of the PCN-decision-node, which in the main body of this memo is
   assumed to coincide with the PCN-ingress-node.  The decision cycle is
   repeated each time a set of measurements is received from the egress
   node.  The outcome of the decision is a flow termination state (flow
   termination required/not required), an admission state (accept or
   block new flows), and, when flow termination is required, an estimate
   of the amount of traffic that must be terminated.  The steps in the
   process are as follows:

   1.  Determine whether flow termination is required.

   2.  If flow termination is required:

       A.  Set the admission state to "block".

       B.  Estimate the amount of traffic that must be terminated.

       C.  Select currently admitted flows based on policy and terminate
           them until the termination quota has been reached.

   3.  If flow termination is not required, determine whether the
       admission state is "admit" or "block".

   4.  While the admission state is "block", block all new flows offered
       to the ingress-egress-aggregate unless policy overrides this
       decision for specific flows.

   In the next few sections, the symbols NM-rate, ThM-rate, and ETM-rate
   designate the rates reported by an egress node for the most recent
   measurement period, for unmarked, threshold-marked, and excess-
   traffic-marked PCN-traffic respectively.

3.2.1.  Determining Whether Flow Termination Is Required

   If the value ETM-rate for the measurement period is greater than zero
   (i.e., excess-traffic-marked packets were observed), flow termination
   is required.




Charny, et al.          Expires September 3, 2009               [Page 6]

Internet-Draft       PCN CL Boundary Node Behaviour           March 2009


3.2.2.  Estimating the Amount of Traffic To Terminate

   To determine how much traffic to terminate, the ingress node must
   first measure the rate of PCN-traffic being sent (octets per second)
   as discussed in Section 3.1.  Call this quantity the Send-rate.

   The estimate of how much traffic to terminate is based on the
   assumption that the sum:

      NM-rate + ThM-rate

   of unmarked and threshold-marked PCN-traffic represents the current
   edge-to-edge supportable rate of flow of PCN-traffic.  The estimate
   of how much traffic to terminate is then the difference:

      Send-rate - (NM-rate + ThM-rate).

3.2.3.  Flow Admission Decisions

   This section describes the logic used to set the flow admission state
   in periods when flow termination is not taking place.

   Two running estimates ThMavg and Totavg are maintained, of the
   average rate of threshold-marked traffic and the average rate of
   total traffic received.  These estimates MUST NOT be updated in
   periods when excess-marked traffic is observed (hence ETM-rate will
   be 0 and can be ignored).  Because traffic rates will be time-
   varying, the average rates SHOULD be calculated using exponential
   smoothing, as follows:

      ThMavg(updated) = (1-a)*ThMavg(previous) + a*ThM-rate; and

      Totavg(updated) = (1-a)*Totavg(previous) + a*(NM-rate + ThM-rate),

   The constant a is tuned to provide the optimal tradeoff between
   tracking current traffic conditions and eliminating excessive
   volatility.  The appropriate value is in the order of 1000/D to
   3000/D, where D is the reported measurement period duration in
   milliseconds.

   Following the update of the running estimates the ratio

      ThMavg / Totavg

   is calculated.  If this ratio exceeds a configured decision value (of
   the order of 0.5), the admission state MUST be set to "block".  If
   the ratio is less than or equal to the decision value, the admission
   state is set to "admit".  The admission state remains in effect until



Charny, et al.          Expires September 3, 2009               [Page 7]

Internet-Draft       PCN CL Boundary Node Behaviour           March 2009


   new measurements in the next or a later period cause the ratio to
   drop below (rise above, respectively) the decision value.


4.  Assumed Signalling Flows

4.1.  Assumed Signalling To Support Classification

   In all boundary node behaviours, it is necessary for the edge nodes
   to be provided with the means to distinguish between the flows for
   different ingress-egress-aggregates.  The means by which the PCN-
   egress-node obtains this information is deployment-dependent.  For
   instance, if aggregates are passed directly from ingress to egress
   using tunnels, the tunnel identifier can be used for packet
   classification.  Alternatively, ingress and egress may exchange
   signalling to provide each other with the necessary classifying
   information.

4.2.  Assumed Signalling Of Measurements

   This memo specifies signalling from egress to ingress to report the
   values of NM-rate, ThM-rate, and ETM-rate at the end of each
   measurement period, along with the measurement period duration D.


5.  Deployment Considerations

   Have to pull these together.


6.  Security Considerations

   [ID.PCNArch] provides a general description of the security
   considerations for PCN.  This memo introduces no new considerations.


7.  IANA Considerations

   This memo includes no request to IANA.


8.  Acknowledgements

   Excluding the appendices, the content of this memo is drawn from
   [ID.briscoe-CL].  The authors of that document were Bob Briscoe,
   Philip Eardley, and Dave Songhurst of BT, Anna Charny and Francois Le
   Faucheur of Cisco, Jozef Babiarz, Kwok Ho Chan, and Stephen Dudley of
   Nortel, Giorgios Karagiannis of U. Twente and Ericsson, and Attila



Charny, et al.          Expires September 3, 2009               [Page 8]

Internet-Draft       PCN CL Boundary Node Behaviour           March 2009


   Bader and Lars Westberg of Ericsson.


9.  References

9.1.  Normative References

   [ID.PCN-baseline]
              Moncaster, T., Briscoe, B., and M. Menth, "Baseline
              Encoding and Transport of Pre-Congestion Information (Work
              in progress)", 2009.

   [ID.PCN-marking]
              Eardley, P., "Marking behaviour of PCN-nodes (Work in
              progress)", 2008.

   [ID.PCNArch]
              Eardley, P., "Pre-Congestion Notification (PCN)
              Architecture (Work in progress)", 2009.

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

9.2.  Informative References

   [ID.PCN3in1]
              Briscoe, B., "PCN 3-State Encoding Extension in a single
              DSCP (Work in progress)", 2008.

   [ID.PCN3state]
              Moncaster, T., Briscoe, B., and M. Menth, "A three state
              extended PCN encoding scheme (Work in progress)", 2008.

   [ID.briscoe-CL]
              Briscoe, B., "An edge-to-edge Deployment Model for Pre-
              Congestion Notification:  Admission Control over a
              DiffServ Region (expired Internet Draft)", 2006.


Appendix A.  Operation With Standalone PCN-Decision-Node

   This Appendix describes a mode of operation that falls outside the
   current charter of the PCN Working Group, but reflects an
   architecture being considered by the ITU-T.

   If the PCN-decision node is a separate entity, the following
   modifications apply to the description in the main body of this memo:




Charny, et al.          Expires September 3, 2009               [Page 9]

Internet-Draft       PCN CL Boundary Node Behaviour           March 2009


   o  The PCN-egress-node reports its measurements to the PCN-decision-
      node rather than the PCN-ingress-node.  As a result, it MAY report
      results for multiple ingress-egress-aggregates at once, suitably
      labelled, if their measurement periods all end at the same time.

   o  When the PCN-decision-node receives a report that indicates a non-
      zero rate of excess-traffic-marking, it must acquire the value of
      Send-rate from the PCN-ingress node in order to calculate how much
      traffic to terminate.  It may do this by sending a request and
      receiving the value in a response.  Alternatively, the PCN-
      ingress-node may measure PCN-sent-traffic continuously and report
      Send-rate to the PCN-decision-node at the end of each measurement
      period for each ingress-egress-aggregate it deals with.  The
      appropriate approach is an open issue.

   o  The PCN-decision-node selects the flows for termination when this
      is required and pushes the necessary policy updates to the PCN-
      ingress-node.

   o  Depending on whether the push or pull model is applicable, the
      PCN-decision-node pushes changes to current admission policy for a
      given ingress-egress-aggregate to the PCN-ingress-node, or the
      PCN-ingress-node requests a decision for each new flow.


Authors' Addresses

   Anna Charny
   Cisco Systems
   300 Apollo Drive
   Chelmsford, MA  01824
   USA

   Email: acharny@cisco.com


   Fortune Huang
   Huawei Technologies
   Section F, Huawei Industrial Base,
   Bantian Longgang, Shenzhen  518129
   P.R. China

   Phone: +86 15013838060
   Email: fqhuang@huawei.com







Charny, et al.          Expires September 3, 2009              [Page 10]

Internet-Draft       PCN CL Boundary Node Behaviour           March 2009


   Michael Menth
   University of Wuerzburg
   Am Hubland
   Wuerzburg  D-97074
   Germany

   Phone: +49-931-888-6644
   Email: menth@informatik.uni-wuerzburg.de


   Tom Taylor (editor)
   Huawei Technologies
   1852 Lorraine Ave
   Ottawa, Ontario  K1H 6Z8
   Canada

   Phone: +1 613 680 2675
   Email: tom.taylor@rogers.com

































Charny, et al.          Expires September 3, 2009              [Page 11]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/