One document matched: draft-karagiannis-pcn-hose-edge-behaviour-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-24 07:22:11 |