Internet Engineering Task Force                           G. Karagiannis
Internet-Draft                                      University of Twente
Intended status: Informational                               L. Westberg
Expires: April 16, 2010                                G. Apostolopoulos
                                                                Ericsson
                                                        October 16, 2009






    PCN Boundary Node Behaviour for the HOSE Mode of
                               Operation
                  draft-karagiannis-pcn-hose-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 April 16, 2010.

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





Karagiannis, et al.       Expires April 16, 2010                [Page 1]

Internet-Draft       PCN HOSE Boundary Node Behaviour       October 2009


   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

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 RFC 5559.  This memo is one
   of a series describing possible boundary node behaviours for a PCN
   domain.  The behaviour described here is denoted as the HOSE model.

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  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Assumed Core Network Behaviour for HOSE  . . . . . . . . . . .  4
   3.  Node Behaviours  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Behaviour of the PCN-Egress-Node . . . . . . . . . . . . .  7
       3.2.1.  PCN-Egress-Node Role In Flow Admission . . . . . . . .  9
       3.2.2.  PCN-Egress-Node Role in Flow Termination . . . . . . .  9
     3.3.  Behaviour of the PCN-Ingress-Node  . . . . . . . . . . . . 12
       3.3.1.  PCN-Ingress-Node Role In Flow Admission  . . . . . . . 13
       3.3.2.  PCN-Ingress-Node Role In Flow Termination  . . . . . . 14
   4.  Specification of Diffserv Per-Domain Behaviour . . . . . . . . 14
     4.1.  Applicability  . . . . . . . . . . . . . . . . . . . . . . 14
     4.2.  Technical Specification  . . . . . . . . . . . . . . . . . 14
     4.3.  Attributes . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.4.  Parameters . . . . . . . . . . . . . . . . . . . . . . . . 15
     4.5.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . 15
     4.6.  Example Uses . . . . . . . . . . . . . . . . . . . . . . . 15
     4.7.  Environmental Concerns . . . . . . . . . . . . . . . . . . 15
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17






Karagiannis, et al.      Expires April, 19, 2010                [Page 2]


Internet-Draft       PCN HOSE Boundary Node Behaviour      October 2009


1.  Introduction


   The main objective of Pre-Congestion Notification (PCN) is to support
   The quality of service (QoS) of inelastic flows within a Diffserv
   domain, in a simple, scalable, and robust fashion.  Two mechanisms
   are used: admission control and flow termination. Admission control
   is used to decide whether to admit or block a new flow request, while
   flow termination is used in abnormal circumstances to decide
   whether to terminate some of the existing flows.  To support these
   two features the overall rate of PCN-traffic is metered on every link
   in the domain, and PCN-packets are appropriately marked when certain
   configured rates are exceeded.  These configured rates are below the
   rate of the link thus providing notification to boundary nodes about
   overloads before any congestion occurs (hence "pre-congestion"
   notification).  The level of marking allows boundary nodes to make
   decisions about whether to admit or terminate.  For more details see
   [RFC5559].

   Boundary node behaviours specify a detailed set of algorithms and
   edge node behaviours used to implement the PCN mechanisms.  Since the
   algorithms depend on specific metering and marking behaviour at the
   interior nodes, it is also necessary to specify the assumptions made
   about interior node behaviour.  Finally, because PCN uses DSCP values
   to carry its markings, a specification of boundary node behaviour
   must include the per domain behaviour (PDB) template specified in
   [RFC3086], filled out with the appropriate content.  This document
   describes this behaviour for the HOSE model of operation, see
   e.g., [DuGo99].  In this document the term HOSE is referring to the
   aggregation of incoming traffic from all ingress edges, which is
   associated with one traffic class, i.e., PHB, towards one egress
   edge.  This type of HOSE model is equivalent to the Multiple Point to
   Point (MP2P) type of aggregation.

   The HOSE model ensures bandwidth limits without the need of
   maintaining per each ingress and egress pair ingress-egress-
   aggregated states.  In this case all edges maintain one aggregated
   state per each traffic class, i.e., PHB (Per Hop Behaviour), used in
   the PCN domain. Moreover, the HOSE model is able to provide solutions
   for the ECMP (Equal Cost Multi Path) problem for both admission
   control and flow termination procedures.


1.1.  Terminology

   In addition to the terms defined in [RFC5559], this document uses the
   following terms:

   Admission block state
      The state ("admit" or "block") derived by PCN-egress-node
      based on PCN packet marking statistics.

Karagiannis, et al.       Expires April, 19, 2010               [Page 3]


Internet-Draft       PCN HOSE Boundary Node Behaviour       October 2009



   Flow termination state
      The operating state of the PCN edges during periods of severe
      overload & congested situations.

   Normal state
      The operating state of the PCN edges during periods when the PCN
      edges are neither operating in Admission block state nor operating
      in Flow termination state.


   Admission block decision threshold rate
      A rate value of ThM marked packets belonging to one PHB that are
      received by a PCN-egress-node and is used for its comparison with
      the measured ThM rate of packets received by the PCN-egress-node
      and that are belonging to the same PHB. If the measured ThM rate
      is higher than this threshold rate than the Normal state changes
      to Admission block state.



2.  Assumed Core Network Behaviour for HOSE

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

   o  encoding of PCN status within individual packets is based on
      [draft-ietf-pcn-3-state-encoding-00] (or on
      [draft-ietf-pcn-3-in-1-encoding-00], extended to provide a
      third PCN encoding state.

   o  the PCN domain satisfies the conditions specified in the
      applicable encoding 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;










Karagiannis, et al.      Expires April 16, 2010                [Page 4]


Internet-Draft       HOSE Boundary Node Behaviour          October 2009



   o  PCN-interior-nodes perform threshold-marking and excess-traffic-
      marking of packets according to the rules specified in
      [draft-ietf-pcn-marking-behaviour-05], and any additional rules
      specified in the applicable encoding extension document, with the
      following recommendations:
        o in situations that the interior node is overloaded it is
          RECOMMENDED that the interior SHOULD preferentially drop
          unmarked packets instead of marked packets. This is required
          since the marked packets are used at the egress to calculate
          the excess rate during flow termination. The excess rate can
          be accurately calculated at the egress when marked packets are
          not dropped in the Core network.

  o   the signaling messages that are passing through a PCN-interior-
    node are treated, from the point of PCN encoding, identically as
    the data packets that are processed by a PCN-interior-node.
    However, the signaling messages SHOULD be processed with a higher
    priority than data packets. This will ensure that in situations of
    severe overload the signaling messages could have a higher chance
    of not being dropped.

   According to [draft-ietf-pcn-marking-behaviour-05], the encoding
   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 the following:


   o  It MUST NOT change the not-PCN codepoint to any other codepoint.

   o  It MAY change any Not-marked codepoint to either the Threshold-
      marked or Excess-traffic-marked codepoints.

   o  It MUST NOT change a Not-marked codepoint to the not-PCN
      codepoint.

   o  A Not-marked codepoint MUST NOT be changed to any other Not-marked
      codepoint.

   o  It MAY change the ThM codepoint to the ETM codepoint but it MUST
      NOT change the ThM codepoint to any other codepoint.

   o  It MUST NOT change the ETM codepoint to any other codepoint.

   Obviously in every case a codepoint can remain unchanged.  The
   precise rules governing which valid transition to use are set out in
   [draft-ietf-pcn-marking-behaviour-05].


Karagiannis, et al.      Expires April 16, 2010                [Page 5]

Internet-Draft       HOSE Boundary Node Behaviour          October 2009


3.  Node Behaviours

3.1.  Overview

   The HOSE model assumes that on-path admission control signalling
   Messages, e.g., RSVP PATH, are used from a PCN-ingress-node towards a
   PCN-egress-node. The HOSE mode of operation supports flow admission
   based on the received ThM marked traffic rate, belonging to the same
   PHB. If the ThM marked rate is higher than a predefined value then
   the state at the PCN-egress-node changes from Normal to Admission
   block state. The PCN-egress-node MUST be able to identify signalling
   request messages and at the same time separate them from received
   data packets. A flow is rejected if the following two conditions are
   valid:
       o the PCN-egress-node operates in Admission block state
       o the admission control signalling request message is
         ThM marked.

   By observing these two conditions, it is ensured that the aggregation
   level of the measured ThM packets at the PCN-egress-node is
   relatively high and accurate enough to identify that the PCN-egress-
   node operates in the Admission block state and at the same time it
   ensures that the admission control signalling request message passed
   through a PCN-interior-node that is in a congestion situation. This
   solution solves among other problems also the ECMP problem that can
   occur during admission control. By using an admission control
   signalling reply message, e.g., RSVP PATHErr, the PCN-ingress-node is
   notified that the flow is rejected. If these two conditions are not
   satisfied then the flow is accepted and the PCN-ingress-node is
   notified by using an admission control signalling reply message,
   e.g., RSVP RESV.

   Flow termination is triggered when the PCN-egress-node receives
   excess-traffic-marked (ETM) packets, belonging to the same PHB.
   If the egress node is in Flow termination state then the egress has
   to calculate how many flows have to be terminated by using the
   received ETM rate. The edge nodes keep per flow state and therefore
   they can translate the calculated ETM rate to be terminated, to
   number of flows. Moreover, the PCN-egress-node records the address
   identity of the PCN-ingress-node and the identity of all the flows
   arriving at the PCN-egress-node, that are ETM marked. Only these
   flows, which are the ones passing through the severely overloaded
   PCN-interior-node(s), are candidates for termination. This
   solution solves among other problems also the ECMP problem that can
   occur during flow termination. The PCN-egress-node informs each PCN-
   ingress-node about which flows should be terminated by sending to
   each of them a list with flows that have been selected for
   termination. This information can be sent in a reliable way using a
   flow termination signalling notify message, e.g., RSVP-TE Notify
   message. The PCN-ingress-node, using admission control signalling
   procedures must terminate these flows.


Karagiannis, et al.      Expires April 16, 2010                [Page 6]

Internet-Draft       HOSE Boundary Node Behaviour           October 2009


3.2.  Behaviour of the PCN-Egress-Node

  The egress node observes all PCN-traffic that it receives, ThM marked
  traffic, excess marked-traffic (ETM) and PCN unmarked traffic in order
  to define the state mode that the egress node is operating. Based on
  this operation state the PCN-egress-node decides to either admit,
  reject or terminate a flow. It is considered that the PCN-egress-node,
  in addition to the PCN-related functions described briefly in section
4.3 of [RFC5559] is able to support the following:

o  it measures the following rates during fixed-length measurement
   intervals with a duration of T, where the duration is suggested
   to be in the range of 50 to 100ms:

   NM_count:
      Number of bytes of PCN-traffic contained in received packets
      which are neither threshold-marked nor excess-traffic-marked.

   ThM_count:
      Number of bytes of PCN-traffic contained in received packets
      which are threshold-marked.

   ETM_count:
      Number of bytes of PCN-traffic contained in received packets which
      are excess-traffic-marked.

   NM_rate
      Rate of PCN-traffic contained in received packets
      which are neither threshold-marked nor excess-traffic-marked;
      NM_rate = NM_count/T;

   ThM_rate
      Rate of PCN-traffic contained in received packets
      which are threshold-marked; ThM_rate = ThM_count/T;

   ETM_rate
      Rate of PCN-traffic contained in received packets which
      are excess-traffic-marked; ETM_rate = ETM_count/T;

o Ablock_TH
      an admission block detection threshold rate is a predefined
      ThM_rate that is used to detect whether a PCN-egress-node should
      change from a Normal state to an Admission block
      state or vice-versa.

o it is considered that the used signaling messages sent from the
  PCN-ingress-node towards the PCN-egress-node are following the data
  path, i.e., the same communication path as the data packets sent from
  the same PCN-ingress-node towards the same PCN-egress-node.

o it is able to differentiate signaling messages from data packets.


Karagiannis, et al.      Expires April 16, 2010                [Page 7]


Internet-Draft       HOSE Boundary Node Behaviour           October 2009


o it is able to identify flows and to classify packets into flows.

o it is able to identify the identity (address information) of the
  PCN-ingress-node that forwarded each flow. For example, in RSVP this
  can be provided using RSVP PHOP.

o it is considered the signaling messages that are used for admission
  control and flow termination purposes are PCN encoded in an identical
  way as data packets. However, the signaling messages SHOULD be
  processed with a higher priority than data packets. This will ensure
  that in situations of severe overload the signaling messages could
  have a higher chance of not being dropped.

The operation states & events in PCN-egress-nodes are shown in Figure 1.

                 ---------------------------------------------
                |        event B                              |
                |                                             V
             ----------             -------------           ----------
            | Normal   |  event A  | Admission   | event B | Flow      |
            |  state   |---------->| block       |-------->|Termination|
            |          |           |  state      |         |  state    |
             ----------             -------------           ----------
              ^  ^                       |                     |
              |  |      event C          |                     |
              |   -----------------------                      |
              |         event D                                |
               ------------------------------------------------

    Figure 1: States of operation

   o event A: when the PCN-egress-node receives a ThM rate that is
     higher or equal than the admission block detection threshold rate
     (Ablock_TH). Note that this predefined ThM threshold rate can be
     set equal to a default rate that is equal to 1% of the rate
     capacity of the link with lowest capacity within the whole PCN
     domain.

   o event B: this event occurs when the PCN-egress-node receives
     packets that are ETM marked.

   o event C: this event occurs when the rate of incoming ThM
     bytes/packets decreases below the Ablock_TH.

   o event D: this event occurs when the egress, during an interval T,
     does not receive ETM marked packets.

   The following sections give details of the egress node operation in
   admission control and flow termination.


Karagiannis, et al.      Expires April 16, 2010                [Page 8]


Internet-Draft       HOSE Boundary Node Behaviour           October 2009


3.2.1.  PCN-Egress-Node Role In Flow Admission

   When the PCN-egress-node operates in Normal state or in Admission
   Block state then the NM_count, NM_rate, ThM_count and ThM_rate
   variables are being calculated each measurement interval, T.
   Furthermore, the following situations can be identified:

o if the PCN-egress-node operates in Normal state and it receives an
  admission control signaling request message forwarded by an PCN-
  ingress-node to check whether a flow can be admitted or not then
  the PCN-egress-node MUST accept the request. In this case the PCN-
  egress-node uses an admission control signaling reply message,
  e.g., RSVP RESV message, to carry an admission control "admit"
  boolean value towards the PCN-ingress-node that initiated the
  request.

o if the PCN-egress-node operates in Admission block state and it
  receives an admission control signaling request message that is
  PCN unmarked then the PCN-egress-node MUST accept the request. In
  this case the PCN-egress-node uses an admission control signaling
  reply message, e.g., RSVP RESV message, to carry an admission
  control "admit" boolean value towards the PCN-ingress-node that
  initiated the request.

o if the PCN-egress-node operates in either Admission block state or
  Flow termination state and it receives an admission control
  signaling request message that is ThM marked then the PCN-egress-
      node MUST reject the request. In this case the PCN-egress-node
  uses an admission control signaling reply message, e.g., RSVP
  PATHErr, to carry an admission control "block" boolean value
  towards the PCN-ingress-node that initiated the request.


3.2.2.  PCN-Egress-Node Role in Flow Termination

   When the PCN-egress-node detects an ETM packet, it changes its
   operation state to Flow Termination state. As a result of
   this transition, it immediately resets NM_count and ThM_count and
   begins a new measurement interval. In addition, it begins to collect
   the ETM_count and ETM_rate variables.

   The ETM_rate variable represents the bandwidth that causes an
   overload on a communication path within the PCN domain.

   The PCN edge nodes keep per flow state and therefore they can
   translate the calculated bandwidth to be terminated, to number of
   flows.



Karagiannis, et al.      Expires April 16, 2010                [Page 9]


Internet-Draft       HOSE Boundary Node Behaviour           October 2009


   In Flow termination, inaccuracies in excess rate measurements might
   occur due to the delay between the metering and marking event that
   occurs at the PCN-interior-nodes, the decisions that are made at PCN-
   egress-nodes, and the termination of flows that are performed by PCN-
   ingress-nodes, see section 6 in [CsTa05].  Furthermore, until the
   overload decreases at the PCN-interior-node such that the overload
   situation is solved, an additional trip time from the PCN-ingress-
   node to this PCN-interior-node can expire.  This is because
   immediately before receiving the flow termination notification, the
   PCN-ingress-node may have sent out packets associated with the flows
   that were selected for termination. Without considering the above,
   PCN-interior-nodes would continue marking the packets until the
   overload situation is solved. In this way, at the end more flows will
   be terminated than necessary, i.e., an over-reaction takes place. In
   order to solve these inaccuracies, the PCN- egress-nodes use a
   sliding window memory to keep track of the measured ETM_rate in a
   couple of previous measurement intervals. At the end of a measurement
   interval, T, the bandwidth that needs to be terminated (denoted below
   as termination_PCN_marking_rate) is calculated as follows. The
   ETM_rate value measured  during one T interval is decreased with the
   sum of already ETM_rate values stored in the sliding window memory,
   since that bandwidth to be terminated is already being handled in the
   flow termination handling control loop. The sliding window memory
   consists of an integer number of cells, i.e, n =maximum number of
   cells.  Thus the maximum size of the sliding window memory is
   represented by n. Guidelines for configuring the sliding window
   parameters are given in [CsTa05].  However, based on several
   experiments that have been performed for the situation that the
   sliding window is applied at the PCN-egress-node, it is recommended
   that the best value that can be used for the sliding window size at
   the egress is equal to 1, i.e., n = 1. At the end of each measurement
   interval, the newest calculated ETM_rate is pushed into the memory
   with maximum size n, and the oldest cell is dropped.

   If Mi is the ETM_rate stored in ith memory
   cell (i = [1..n]), then at the end of every measurement interval, the
   termination_PCN_marking_rate variable that is used to calculate the
   bandwidth that has to be terminated is calculated as follows:


   The PCN-egress-node keep per flow state and therefore it can
   translate the calculated bandwidth to be terminated, to number of
   flows.








Karagiannis, et al.      Expires April 16, 2010                [Page 10]


Internet-Draft       HOSE Boundary Node Behaviour           October 2009


       Sum_Mi =0
       For i =1 to n
       {
         Sum_Mi = Sum_Mi + Mi
       }

       termination_PCN_marking_rate  =
              ETM_rate - Sum_Mi,

       where Sum_Mi is calculated as above.

       Next, the sliding memory is updated as follows:

       For i = 1..(n-1): Mi = Mi+1
              Mn = termination_PCN_marking_rate

   The PCN-egress-node records the identity of the PCN-ingress-node that
   forwarded each flow, the ETM_rate and the identity of all the flows,
   arriving at the PCN-egress-node, with ETM marking. This ensures that
   only these flows, which are the ones passing through the severely
   overloaded interior node(s), are candidates for termination.
   The selection of the flows to be terminated is described in the
   pseudo-code that is given below, which is realized by the function
   denoted below as calculate_terminate_flows().

    terminated_bandwidth = 0;
    while terminated_bandwidth < termination_PCN_marking_rate
    {
      terminate_bandwidth_class =
         termination_PCN_marking_rate - terminated_bandwidth
      calculate_terminate_flows();
      sum_bandwidth_terminate;
      terminated_bandwidth =
         sum_bandwidth_terminate + terminated_bandwidth;
    }

   The term denoted as termination_PCN_marking_rate is the calculated
   bandwidth to be terminated, which was derived using the sliding
   window algorithm described above. The terminate_bandwidth_class
   variable represents the calculated bandwith that has to be translated
   in a number flows that should be terminated. The
   calculate_terminate_flows() function uses the
   terminate_bandwidth_class value and translates this bandwidth value
   to number of flows that have to be terminated. Only the ETM marked
   flows, which are the ones passing through the severely overloaded
   interior node(s), are candidates for termination. After the flows to
   be terminated are selected the sum_bandwidth_terminate value is
   calculated that is the sum of the bandwidth associated with the flows
   that will certainly be terminated.



Karagiannis, et al.      Expires April 16, 2010                [Page 11]


Internet-Draft       HOSE Boundary Node Behaviour           October 2009


   The constraint of finding the
   total number of flows that have to be terminated is that the
   sum_bandwidth_terminate(priority_class) should be smaller
   approximately equal to the variable terminate_bandwidth_class.

   Finally the PCN-egress-node informs each PCN-ingress-node about
   which flows should be terminated by sending to each of them a list
   with flow IDs of flows that have been selected for termination. This
   information can be sent in a reliable way using a flow termination
   signalling notify message, e.g., RSVP-TE Notify message. The reliable
   term means in this context that the PCN-egress-node should be
   informed, by using e.g., an acknowledgement that the flow termination
   signalling notify message is successfully received by the
   PCN-ingress-node.

3.3.  Behaviour of the PCN-Ingress-Node

   The PCN-related functions of the PCN-ingress-node are described
   briefly in section 4.2 of [RFC5559].  This section focuses on the
   specific behaviour associated with admission and flow termination.
   It is considered that the PCN-ingress-node, in addition to the PCN-
   related functions described briefly in section 4.2 of [RFC5559], is
   able to support the following:

   o it is considered that a signaling protocol can be used for
     admission control and flow termination, to admit and reject new
     flows and terminate ongoing flows. Furthermore, it is considered
     that the signaling messages are using the same flow ID information
     and PCN encoding states as the data packets associated with these
     signalling messages.

   o it is considered that the used signaling messages sent from the
     PCN-ingress-node towards the PCN-egress-node are following the data
     path, i.e., the same communication path as the data packets sent
     from the same PCN-ingress-node towards the same PCN-egress-node.

   o it is able to differentiate signaling messages from data packets.

   o it is able to identify flows and to classify packets into flows.

   o it is able to identify the identity (address information) of the
     PCN-egress-node that notifies the PCN-ingress-node about admission
     control and flow termination decisions.

   o it is considered the signaling messages that are used for admission
     control and flow termination purposes are PCN encoded in an
   identical way as data packets. However, the signaling messages
   SHOULD be processed with a higher priority than data packets. This
   will ensure that in situations of severe overload the signaling
   messages could have a higher chance of not being dropped.


Karagiannis, et al.      Expires April 16, 2010                [Page 12]


Internet-Draft       HOSE Boundary Node Behaviour           October 2009


 The operation states & events in PCN-ingress-nodes are shown in
 Figure 2.


           ----------                  -------------
           | Normal   |  event B      | Flow        |
           |  state   |-------------->| termination |
           |          |               |  state      |
            ----------                 -------------
                ^                           |
                |      event E              |
                 ---------------------------

         Figure 2: State of operation at a PCN-ingress-node

The events used in Figure 2 and applied for PCN-ingress-nodes are:

   o  event B: this event occurs when the PCN-ingress-node receives one
      Flow termination signaling notification message, e.g., RSVT-TE
      Notify, from the PCN-egress-node that one or more flows have to be
      terminated due to the fact that the PCN-egress-node operates in
      the Flow termination operational state. In Flow termination, and
      if the PCN-ingress-node is able to identify, for each new
      admission flow request received from outside the PCN domain, to
      which PCN-egress-node is being destined, then the PCN-ingress-node
      SHOULD block all new admission flow requests that are received by
      the PCN-ingress-node from outside the PCN domain towards the PCN-
      egress-nodes that are operating in flow termination state.
      Otherwise, the PCN-ingress-node SHOULD block all new admission
      flow requests, that are received by the PCN-ingress-node from
      outside the PCN domain and sent towards any PCN-egress-node.

   o event E: this event is activated after the moment that the
     signaling protocol informs the PCN-ingress-node that the
     termination of all notified flows is completed.

3.3.1.  PCN-Ingress-Node Role In Flow Admission

   The PCN-ingress-node receives an admission control signalling
   request message belonging to an external to PCN, signalling protocol.
   Subsequently, the PCN-ingress-node sends the admission control
   signalling request message towards the PCN-egress-node.

   When the PCN-ingress-node receives an admission control signalling
   report message, e.g., RSVP RESV, that includes a report indicating
   "admit", it admits the flow that requested access to the PCN domain.
   When the PCN-ingress-node receives an admission control signalling
   report message, e.g., RSVP PATHErr, that includes a report indicating
   "block", it rejects the flow that requested access to the PCN domain.


Karagiannis, et al.      Expires April 16, 2010                [Page 13]


Internet-Draft       HOSE Boundary Node Behaviour           October 2009


3.3.2.  PCN-Ingress-Node Role In Flow Termination

   The PCN-Ingress-Node changes its operation state from Normal to Flow
   termination state when it receives one Flow termination signaling
   notification message, e.g., RSVT-TE Notify, from the PCN-egress-node
   that requires that one or more flows have to be terminated. The flow
   IDs of the flows that must be terminated are carried within a list by
   the flow termination signaling notification message in a list. The
   signaling protocol SHOULD be used to terminate all flows with flow
   IDs included in the received flow ID list. Moreover, in Flow
   termination, see event B, and if the PCN-ingress-node is able to
   identify, for each new admission flow request received from outside
   the PCN domain, to which PCN-egress-node is being destined, then the
   PCN-ingress-node SHOULD block all new admission flow requests that
   are received by the PCN-ingress-node from outside the PCN domain
   towards the PCN-egress-nodes that are operating in flow termination
   state. Otherwise, the PCN-ingress-node SHOULD block all new admission
   flow requests, that are received by the PCN-ingress-node from outside
   the PCN domain and sent towards any PCN-egress-node.

4.  Specification of Diffserv Per-Domain Behaviour

   This section provides the specification required by [RFC3086] for a
   per-domain behaviour.

4.1.  Applicability

   This section draws heavily upon points made in the PCN architecture
   document, [RFC5559].

   The HOSE boundary node behaviour specified in this document is
   applicable to inelastic traffic where the QoS for admitted flows is
   protected primarily by admission control at the ingress to the
   domain.  In exceptional circumstances (e.g. due to network failures)
   already-admitted flows may be terminated to protect the quality of
   service of the remainder on-going flows.

4.2.  Technical Specification

   The technical specification of the HOSE per domain behaviour is
   provided by the contents of [RFC5559],
   [draft-ietf-pcn-baseline-encoding-07],
   [draft-ietf-pcn-marking-behaviour-05], the specification of the
   encoding extension (e.g., [draft-ietf-pcn-3-state-encoding-00],
   [draft-ietf-pcn-3-in-1-encoding-00]) and the present document.

4.3.  Attributes

   The basic attributes are low loss and low jitter.



Karagiannis, et al.      Expires April 16, 2010                [Page 14]


Internet-Draft       HOSE Boundary Node Behaviour           October 2009


4.4.  Parameters

   The relevant parameters are loss and jitter.

4.5.  Assumptions

   Assumed that a specific portion of link capacity has been reserved
   for PCN traffic.  Assumed that recovery from overloads by flow
   termination should happen within 1-3 seconds.

4.6.  Example Uses

   The HOSE behaviour may be used to carry real-time traffic,
   particularly voice and video.

4.7.  Environmental Concerns

   In some markets, traffic pre-emption is considered to be
   impermissible.  In such environments, flow termination would not be
   enabled.

5.  Security Considerations

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


6.  IANA Considerations

   This memo includes no request to IANA.


7.  Acknowledgements

   Parts of the content used in this memo are drawn from
   [draft-westberg-pcn-load-control-05]. Therefore, we would like to
   acknowledge the authors of that draft, which are: L. Westberg, A.
   Bhargava, A. Bader, G. Karagiannis, H. Mekkes.
   The template and parts of the text that are used in this memo are
   based on the template used in [draft-ietf-pcn-cl-edge-behaviour-00].
   Therefore, we would like to acknowledge the authors of that draft,
   which are: A, Charny, F. Huang, G. Karagiannis, M. Menth, T. Taylor.
   We would also like to acknowledge Arjen Holtzer from TNO for
   providing useful comments.



Karagiannis, et al.      Expires April 16, 2010                [Page 15]

Internet-Draft       HOSE Boundary Node Behaviour           October 2009


8.  References

8.1.  Normative References

   [draft-ietf-pcn-baseline-encoding-07]
              Moncaster, T., Briscoe, B., and M. Menth, "Baseline
              Encoding and Transport of Pre-Congestion Information (Work
              in progress)", May 2009.

   [draft-ietf-pcn-marking-behaviour-05]
              Eardley, P., "Metering and marking behaviour of PCN-nodes
              (Work in progress)", August 2009.

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

   [RFC5559]  Eardley, P., "Pre-Congestion Notification (PCN)
              Architecture", RFC 5559, June 2009.


8.2.  Informative References

   [CsTa05]   Csaszar, A., Takacs, A., Szabo, R., and T. Henk,
              "Resilient Reduced-State Resource Reservation", Journal of
              Communication and Networks Vol. 7, Num. 4, December 2005.

   [draft-ietf-pcn-3-in-1-encoding-00])
              Briscoe, B., "PCN 3-State Encoding Extension in a single
              DSCP (Work in progress)", July 2009.

   [draft-ietf-pcn-3-state-encoding-00],
              Moncaster, T., Briscoe, B., and M. Menth, "A PCN encoding
              using 2 DSCPs to provide 3 or more states (Work in
              progress)", April 2009.

    [draft-ietf-pcn-cl-edge-behaviour-00] T. Taylor, A, Charny,
              F. Huang, G. Karagiannis, M. Menth, "PCN Boundary Node
              Behaviour for the Controlled Load (CL) Mode of Operation
              (Work in progress)", July 2009.

    [draft-westberg-pcn-load-control-05], L. Westberg, A. Bhargava,
              A. Bader, G. Karagiannis, H. Mekkes, "LC-PCN: The Load
              Control PCN Solution (Work in progress)", November 2008.

    [DuGo99]  Duffield, N. and P. Goyal, "A Flexible  Model for
              Resource Management in Virtual Private", Proc. of
              ACM/SIGCOMM pp. 95 - 108, December 1999.

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

Karagiannis, et al.      Expires April 16, 2010                [Page 16]


Internet-Draft       HOSE Boundary Node Behaviour           October 2009


   Authors' Addresses

   Georgios Karagiannis
   University of Twente
   P.O. BOX 217
   7500 AE Enschede,
   The Netherlands
   EMail: g.karagiannis@ewi.utwente.nl

   Lars Westberg
   Ericsson AB
   SE-164 80 Stockholm
   Sweden
   EMail: Lars.Westberg@ericsson.com

   George Apostolopoulos
   Ericsson
   4333 Still Creek Dr.Burnaby,
   BC, V5C 6C6
   Canada
   Email: george.apostolopoulos@ericsson.com






























Karagiannis, et al.      Expires April 16, 2010                [Page 17]


Internet-Draft       HOSE Boundary Node Behaviour           October 2009