One document matched: draft-menth-pcn-psdm-deployment-00.txt
Internet Engineering Task Force M. Menth
Internet-Draft University of Wuerzburg
Expires: April 27, 2009 October 24, 2008
Deployment Models for PCN-Based Admission Control and Flow Termination
Using Packet-Specific Dual Marking (PSDM)
draft-menth-pcn-psdm-deployment-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2009.
Menth Expires April 27, 2009 [Page 1]
Internet-Draft PSDM Deployment Models October 2008
Abstract
This document presents different deployment models of PCN-based
admission control (AC) and flow termination (FT) using packet-
specific dual marking (PSDM) for encoding. Their major is that they
require only a single DSCP for packet marking and that they work
reliably in the presence of ingress-egress aggregates (IEAs) with
only a very small average number of flows. Moreover, an advanced
model even works with multipath routing.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Admission Control Methods . . . . . . . . . . . . . . . . . . 7
3.1. Configuration of the Exhaustive Marker . . . . . . . . . . 7
3.2. Admission Control Based on AC States for IEAs (IEABAC)
Using Probe Traffic . . . . . . . . . . . . . . . . . . . 7
3.2.1. Observation-Based AC for IEAs Using Probe Packets . . 7
3.2.2. Congestion Level Estimate (CLE) Based AC for IEAs
Using Probe Packets . . . . . . . . . . . . . . . . . 8
3.3. Implicit per-Flow Probing . . . . . . . . . . . . . . . . 8
3.3.1. A Brief Summary of RSVP . . . . . . . . . . . . . . . 8
3.3.2. Modification of Standard RSVP to Perform PCN-Based
AC . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Flow Termination Methods . . . . . . . . . . . . . . . . . . . 10
4.1. Configuration of the Excess Marker . . . . . . . . . . . . 10
4.2. Direct Measured Rate Termination (DMRT) . . . . . . . . . 10
4.2.1. Operation . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Packet Dropping Policy . . . . . . . . . . . . . . . . 10
4.3. Indirect Measured Rate Termination (IMRT) . . . . . . . . 10
4.3.1. Operation . . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. Required Packet Dropping Policy . . . . . . . . . . . 10
4.4. Marked Flow Termination for IEAs (MFT, MFT-IEA) . . . . . 10
4.4.1. Operation . . . . . . . . . . . . . . . . . . . . . . 10
4.4.2. Required Packet Dropping Policy . . . . . . . . . . . 10
5. Comparison with Other Deployment Models . . . . . . . . . . . 12
5.1. Comparison with the Single-Marking (SM) Deployment
Model . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Comparison with the Control-Load (CL) Deployment Model . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Menth Expires April 27, 2009 [Page 2]
Internet-Draft PSDM Deployment Models October 2008
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Menth Expires April 27, 2009 [Page 3]
Internet-Draft PSDM Deployment Models October 2008
1. Introduction
Pre-congestion notification (PCN) supports admission control (AC) and
flow termination (FT) for high priority flows in a DiffServ region in
order to protect the quality of service (QoS) of inelastic flows
[PCN-arch]. PCN assumes that each link of a network is associated
with a PCN admissible and supportable rate (AR, SR). If its PCN
traffic rate is below AR, the link is not pre-congested, if it is
above AR, the link is AR-pre-congested, and if it is above SR, the
link is SR-pre-congested. In case of AR-pre-congestion, AC should
block new PCN flows using this link and in case of SR-pre-congestion,
FT should terminate sufficiently many PCN flows using this link to
reduce the PCN rate below SR.
Packet meter and markers on links of a so-called PCN domain mark
packets in case of pre-congestion to notify the egress nodes about
the highest pre-congestion level on their paths. The egress nodes
turn this information into AC and FT decisions. Excess traffic
marking marks PCN packets that exceed a certain reference rate on a
link while exhaustive marking marks all PCN packets on a link when
the PCN traffic rate exceeds a reference rate
[PCN-marking-behaviour].
The IP header has not any unused bits. Therefore, the integration of
the marks into the IP header is challenging. A DSCP is chosen to
indicate PCN and the ECN field [RFC3168] is re-used to indicate the
exact marking. Baseline encoding [Baseline] is able to mark packets
as marked and unmarked and therefore it can support either excess
traffic marking or exhaustive marking in a network. Packet-specific
dual marking (PSDM) [PSDM] supports two concurrent marking schemes in
a limited way. There are two different codepoints for unmarked
packets (NM1, NM2) but only one codepoint for marked packets (M).
Both baseline and PSDM encoding require only a single DSCP. For the
remainder of this draft we assume that packets with codepoint NM1 are
subject to excess traffic marking packets with codepoint NM2 are
subject to exhaustive marking. Both marker types possibly re-mark
these packets to M in case of AR- or SR-pre-congestion. To determine
the meaning of a M-marked packet, it is important to know whether it
was NM1- or NM2-marked at the ingress node of the PCN domain. This
is can be achieved by introducing two types of packets: ordinary data
packets of a PCN flow and other distinguishable signalling packets.
These signalling packets may be associated with a flow (e.g. RSVP
signalling packets for that flow) or with an IEA (e.g. explicit probe
packets to maintain its admission state). Note that both kinds of
probing do not require extra packets per flow and do not delay the AC
decision. Other encoding mechanisms are proposed that require two
DSCPs [3state].
Menth Expires April 27, 2009 [Page 4]
Internet-Draft PSDM Deployment Models October 2008
This document proposes three AC methods that rely on exhaustive
marking and three FT methods that rely on excess marking in such a
way that PSDM can be used to encode the markings. Basically, any of
these AC methods can be deployed in combination with any of these FT
methods. The deployment of such PCN-based AC and FT has two major
advantages compared to other deployment models [SM], [CL].
o They require only a single DSCP for packet marking.
o They work reliably even if the average number of flows per IEA is
low.
o Some of them work even in case of multipath routing.
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Menth Expires April 27, 2009 [Page 5]
Internet-Draft PSDM Deployment Models October 2008
2. Terminology
Most of the terminology used in this document is defined in
[PCN-arch]. The following additional terms are defined in this
document:
o Exhaustive marking - generalization of threshold and ramp marking
o IEA - ingress-egress aggregate
Menth Expires April 27, 2009 [Page 6]
Internet-Draft PSDM Deployment Models October 2008
3. Admission Control Methods
In this section we explain three AC methods that rely on PCN feedback
from probe packets. We first explain the assumption on metering and
marking and then present the AC methods. Two of these AC methods
maintain AC states for IEAs while the third AC method implements
implicit probing per flow.
3.1. Configuration of the Exhaustive Marker
The probe packets are marked with NM2 by PCN ingress nodes to
indicate to PCN nodes that they are subject to exhaustive marking.
The reference rate of the exhaustive markers is set to the admissible
rate. It meters and marks all PCN packets and possibly re-marks NM2
marked PCN packets to M.
3.2. Admission Control Based on AC States for IEAs (IEABAC) Using Probe
Traffic
IEABAC assumes that IEA contexts are a priori set up for all IEAs for
which PCN flows should be admitted. An IEA context keeps an AC state
K at the PCN ingress node of the IEA. The AC state K may be either
"admit" or "block". Based on this AC state, the PCN ingress node can
either admit or block further flows for the corresponding IEA. To
update the AC state according to the pre-congestion level of the path
over which the traffic of the IEA is carried, the PCN ingress node
sends in regular intervals extra probe messages addressed to the
corresponding PCN egress node. This signalling traffic is marked as
PCN traffic with NM2 to indicate that it is subject to exhaustive
marking. As exhaustive marking is independent of packet sizes, the
size of the probe packets can be chosen very small probe to minimize
the rate of the signalling traffic. The probe packets have a special
format so that PCN egress nodes recognize them as such for the
corresponding PCN ingress nodes and associate them with the correct
IEA. Based on the markings of the probe packets (NM2, M), the PCN
egress node derives the new AC state for the IEA and sends and
admission-stop or admission-continue message to the corresponding PCN
ingress in order to update the AC state of the IEA. In the following
we propose two approaches for PCN egress nodes to determine the new
AC state of an IEA.
3.2.1. Observation-Based AC for IEAs Using Probe Packets
When the PCN egress node receives an M-marked probe packet, it sends
an admission-stop message to the corresponding PCN ingress node and
sets a timer for the minimum block interval to a configurable value
Tblock. The timer may be reset by consecutive arrivals of M-marked
probe packets. When the timer expires, an admission-continue message
Menth Expires April 27, 2009 [Page 7]
Internet-Draft PSDM Deployment Models October 2008
is sent to the PCN ingress node.
3.2.2. Congestion Level Estimate (CLE) Based AC for IEAs Using Probe
Packets
The PCN-egress-node proceeds in measurement intervals of a
configurable time MI. It tracks the number of missing missing probe
packets or probe packets received with an M-mark during a measurement
interval and at its end it calculates the CLE as the fraction of this
number and the number of overall received and missing probe packets.
If the CLE is smaller than a configurable value TadmCont, an
admission-continue message is sent to the PCN ingress node. If the
CLE is larger than a configurable value TadmStop, an admission-stop
message is sent to the PCN ingress node.
3.3. Implicit per-Flow Probing
We briefly review RSVP and explain how its signalling messages can be
re-used for implicit per-flow probing.
3.3.1. A Brief Summary of RSVP
Realtime flows are usually accompanied by end-to-end signalling. A
popular protocol example is RSVP [RFC2205]. With RSVP, the data
source issues a PATH message which is carried hop-by-hop over the
same path future data packets will go. To that end, the PATH message
uses the same source and destination address as future data packets
and also all other header fields that are possible input for routing
and load balancing decisions need to be the same. When a PATH
message arrives at an RSVP-capable node, a PATH state is established
pointing to the previous hop before the PATH message is forwarded
further downstream. When the PATH message arrives at the
destination, the destination triggers the end-to-end reservation for
the flow by sending a RESV message upstream along the nodes that set
up a PATH state. In these nodes, the RESV message is processed. In
particular, resource admission control is performed for the new flow
request and if it succeeds, the node forwards the RESV message to the
previous hop recorded by the PATH state. This two pass signalling
approach guarantees that the reservation is done on the downstream
path of the future data flow. In contrast to PATH messages, RESV
messages have the source address of the sending node and the
destination address of the hop pointed to by the PATH state. That
way, the information about the downstream next hop of the future data
stream is conveyed to the previous hop and the flow-related
information is stored in a RESV state. RSVP is a soft-state
protocol, i.e., the PATH and RESV control messages are periodically
sent to keep the PATH and RESV states alive and, thereby, the flow
reservations. Admission control needs to be performed for a flow
Menth Expires April 27, 2009 [Page 8]
Internet-Draft PSDM Deployment Models October 2008
only once when no RESV state is set up, yet.
3.3.2. Modification of Standard RSVP to Perform PCN-Based AC
We assume that interior nodes of a PCN domain are RSVP-disabled.
That means, they just forward RSVP messages without processing them
and PCN ingress and egress nodes are neighboring RSVP-capable nodes.
As a consequence, PCN ingress nodes decide whether new flows can be
admitted and carried through domain or not. When the initial PATH
message travels downstream, it is marked with NM2 by the ingress node
to indicate to PCN nodes that this packet is subject to exhaustive
marking. It is possibly re-marked to M and eventually received by
the PCN egress node. If no PATH state can be found for this flow at
the PCN egress node, this PATH message is the first one and not a
REFRESH message. If the PATH message is the first of the flow and if
it is marked with M, the RSVP engine sends back a PATHERR message to
reject the flow. If the PATH message is still marked with NM2, the
RSVP PATH state is established at the PCN egress node and the PATH
message is forwarded further downstream. REFRESH messages are just
forwarded according to standard RSVP. When the PATH message arrives
at the destination and a RESV message is sent back along the nodes
with a PATH state. Eventually, the corresponding RESV message
arrives at the PCN ingress node. When no RESV state is set up yet,
this is the first RESV message and admission control must be
performed. By the mere fact that the RESV message arrives, the PCN
ingress node knows that the corresponding initial PATH message was
not marked. Thus, it can admit any flow for which a new RESV message
arrives.
Note that RSVP is only an example for a two-pass end-to-end
signalling protocol and the principle can be adopted to others.
Menth Expires April 27, 2009 [Page 9]
Internet-Draft PSDM Deployment Models October 2008
4. Flow Termination Methods
In this section we explain three FT methods that rely on PCN feedback
from PCN data packets. We first explain the assumption on metering
and marking and then present the FT methods.
4.1. Configuration of the Excess Marker
The PCN data packets are marked with NM1 by PCN ingress nodes to
indicate to PCN nodes that they are subject to excess marking. The
reference rate of the excess markers is set to the supportable rate.
It meters all NM1-marked PCN packets and possibly re-marks them to M.
Thus, PCN signalling traffic required for AC is not taken into
account, but it is designed to have a low bitrate.
4.2. Direct Measured Rate Termination (DMRT)
4.2.1. Operation
see [Overview]
4.2.2. Packet Dropping Policy
DMRT requires preferential dropping of unmarked (NM1) PCN data
packets, otherwise the termination process can be delayed [FT-PE].
4.3. Indirect Measured Rate Termination (IMRT)
4.3.1. Operation
See [Overview], same mechanism as in [CL].
4.3.2. Required Packet Dropping Policy
IMRT requires preferential dropping of marked (M) PCN data packets,
otherwise significant overtermination can occur [FT-PE].
4.4. Marked Flow Termination for IEAs (MFT, MFT-IEA)
4.4.1. Operation
See [MFT-PE].
4.4.2. Required Packet Dropping Policy
MFT-IEA works optimal when unmarked (NM1) PCN data packets are
preferentially dropped in case of unavoidable PCN packet loss.
However, the termination process is only little delayed without
Menth Expires April 27, 2009 [Page 10]
Internet-Draft PSDM Deployment Models October 2008
preferential dropping of any specially marked PCN packets [MFT-PE].
Menth Expires April 27, 2009 [Page 11]
Internet-Draft PSDM Deployment Models October 2008
5. Comparison with Other Deployment Models
5.1. Comparison with the Single-Marking (SM) Deployment Model
SM [SM] uses only a single marking scheme. Therefore, baseline
encoding [Baseline] can be used for PCN marking which requires also
only a single DSCP. However, SM uses CLE-based AC using feedback
from data packets and as a result, it cannot block when an IEA is
empty. This can lead to significant overadmission [AC-PE].
Furthermore, its termination method can lead to overtermination
[FT-PE] even in the case of single bottlenecks [FT-PE]. Neither the
AC nor the FT part of this method reliably workw in the presence of
multipath routing.
5.2. Comparison with the Control-Load (CL) Deployment Model
CL [CL] uses two marking schemes and requires that packets can be re-
marked to two different codepoints. This cannot be achieved with a
single DSCP [3state]. Spending more than a single DSCP for PCN
encoding seems very expensive. Therefore, the AC mechanism of CL
should be modified, e.g. using one of the mechanisms presented in
this document, so that a single DSCP suffices for PCN encoding.
Like SM, CL is prone to overadmission when the number of expected
flows per IEA is small [AC-PE]. CL's flow termination method is
prone to overtermination in case of quickly changing traffic rates
[FT-PE]. Neither its AC nor its FT method works with multipath
routing.
Menth Expires April 27, 2009 [Page 12]
Internet-Draft PSDM Deployment Models October 2008
6. IANA Considerations
{ToDo}
Menth Expires April 27, 2009 [Page 13]
Internet-Draft PSDM Deployment Models October 2008
7. Security Considerations
{ToDo}
Menth Expires April 27, 2009 [Page 14]
Internet-Draft PSDM Deployment Models October 2008
8. Conclusions
This document presented three methods for admission control and three
methods for flow termination. The AC methods rely on probe packets
which are subject to exhaustive marking and the FT methods rely on
data packets which are subject to excess marking so that packet-
specific dual marking (PSDM) can be used to encode PCN marks which
requires only a single DSCP for PCN. All AC and FT methods work with
when the expected number of flows per ingress-aggregate is small.
Each of the AC methods is compatible with each of the FT methods.
One AC method and one FT method even works with multipath routing.
Those are significant advantages compared to the deployment models
presented in [SM], [CL].
Menth Expires April 27, 2009 [Page 15]
Internet-Draft PSDM Deployment Models October 2008
9. Comments Solicited
Comments and questions are encouraged and very welcome. They can be
addressed to the IETF PCN working group mailing list <pcn@ietf.org>,
and/or to the authors.
Menth Expires April 27, 2009 [Page 16]
Internet-Draft PSDM Deployment Models October 2008
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
10.2. Informative References
[3state] Moncaster, T., "A three state extended PCN encoding
scheme", draft-moncaster-pcn-3-state-encoding-00 (work in
progress), June 2008.
[AC-PE] Menth, M. and F. Lehrieder, "Applicability of PCN-Based
Admission Control", <http://
www3.informatik.uni-wuerzburg.de/staff/menth/Publications/
papers/Menth08-Sub-8.pdf>.
[Baseline]
Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information",
draft-moncaster-pcn-baseline-encoding-02 (work in
progress), July 2008.
[CL] Briscoe, B., "An edge-to-edge Deployment Model for Pre-
Congestion Notification: Admission Control over a DiffServ
Region", draft-briscoe-tsvwg-cl-architecture-04 (work in
progress), October 2006.
[FT-PE] Menth, M. and F. Lehrieder, "PCN-Based Measured Rate
Termination", <http://www3.informatik.uni-wuerzburg.de/
staff/menth/Publications/papers/Menth08-Sub-9.pdf>.
[MFT-PE] Menth, M. and F. Lehrieder, "PCN-Based Marked Flow
Termination", <http://www3.informatik.uni-wuerzburg.de/
staff/menth/Publications/papers/Menth08-PCN-MFT.pdf>.
[Overview]
Menth, M. and et al., "A Survey of PCN-Based Admission
Control and Flow Termination", <http://
Menth Expires April 27, 2009 [Page 17]
Internet-Draft PSDM Deployment Models October 2008
www3.informatik.uni-wuerzburg.de/staff/menth/Publications/
papers/Menth08-PCN-Overview.pdf>.
[PCN-arch]
Eardley, P., "Pre-Congestion Notification Architecture",
draft-ietf-pcn-architecture-03 (work in progress),
February 2008.
[PCN-marking-behaviour]
Eardley, P., "Marking behaviour of PCN-nodes",
draft-eardley-pcn-marking-behaviour-01 (work in progress),
June 2008.
[PSDM] Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe,
"PCN Encoding for Packet-Specific Dual Marking (PSDM)",
Internet-Draft menth-pcn-psdm-encoding-00, June 2008.
[SM] Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre-
Congestion Notification Using Single Marking for Admission
and Termination", draft-charny-pcn-single-marking-03
(work in progress), November 2007.
Menth Expires April 27, 2009 [Page 18]
Internet-Draft PSDM Deployment Models October 2008
Author's Address
Michael Menth
University of Wuerzburg
Am Hubland
Wuerzburg D-97074
Germany
Phone: +49-931-888-6644
Email: menth@informatik.uni-wuerzburg.de
Menth Expires April 27, 2009 [Page 19]
Internet-Draft PSDM Deployment Models October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Menth Expires April 27, 2009 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 01:35:07 |