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