idnits 2.17.1 draft-menth-pcn-marked-signaling-ac-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 28, 2011) is 4806 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5696 (Obsoleted by RFC 6660) == Outdated reference: A later version (-11) exists of draft-ietf-pcn-3-in-1-encoding-04 == Outdated reference: A later version (-15) exists of draft-ietf-pcn-cl-edge-behaviour-08 == Outdated reference: A later version (-02) exists of draft-ietf-pcn-psdm-encoding-01 == Outdated reference: A later version (-12) exists of draft-ietf-pcn-sm-edge-behaviour-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion and Pre-Congestion M. Menth 3 Internet-Draft University of Tuebingen 4 Intended status: Experimental R. Geib 5 Expires: September 1, 2011 Deutsche Telekom 6 February 28, 2011 8 Admission Control Using PCN-Marked Signaling 9 draft-menth-pcn-marked-signaling-ac-00 11 Abstract 13 Pre-congestion notification (PCN) is a means for protecting quality 14 of service for inelastic traffic admitted to a Diffserv domain. The 15 overall PCN architecture is described in RFC5559. This memo is one 16 of a series describing possible boundary node behaviours for a PCN 17 domain. 19 This document proposes an admission control method. It assumes that 20 PCN nodes perform threshold-marking configured with the PCN- 21 admissible-rate on any link. The PCN marking state of an initial 22 signaling message of a flow is used to determine whether the flow 23 should be admitted or blocked. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 1, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Assumed Core Network Behaviour for PCN-marked signaling . . . . 3 62 3. Edge Node Behaviours . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Behavior of PCN-Ingress-Nodes . . . . . . . . . . . . . . . 4 65 3.3. Behavior of PCN-Egress-Nodes . . . . . . . . . . . . . . . 4 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 68 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 The objective of Pre-Congestion Notification (PCN) is to protect the 78 quality of service (QoS) of inelastic flows within a Diffserv domain, 79 in a simple, scalable, and robust fashion. Two mechanisms are used: 80 admission control, to decide whether to admit or block a new flow 81 request, and flow termination to decide whether to terminate some 82 already admitted flows during serious congestion. To achieve this, 83 the overall rate of PCN-traffic is metered on every link in the 84 domain, and PCN-packets are appropriately remarked when certain 85 configured rates are exceeded. These configured rates are below the 86 rate of the link thus providing notification to boundary nodes about 87 overloads before any congestion occurs (hence the "pre" part of pre- 88 congestion notification). For more details see [RFC5559]. 90 This document presents PCN-marked signaling as a method to perform 91 admission control based on PCN information. It requires that all 92 PCN-ingress-nodes perform threshold marking [RFC5670] configured with 93 the PCN-admissible-rate as reference rate, and uses the marking state 94 of initial signaling messages to determine whether flows should be 95 admitted or blocked. It neither describes a corresponding flow 96 termination behavior nor does it preclude flow termination. 98 The proposed method has several benefits: it does not require any 99 measurement, it blocks very quickly as soon as pre-congestion occurs 100 [Menth08-Sub-8], and it works well with multipath routing if 101 signaling messages are carried on the same path as future data 102 packets. 104 1.1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 The terminology defined in [RFC5559] applies. 112 2. Assumed Core Network Behaviour for PCN-marked signaling 114 Admission control using PCN-marked signaling requires that nodes of a 115 PCN-domain perform threshold marking [RFC5670]. The reference rate 116 must be set to the PCN-admissible-rate of a link. Either Baseline 117 Encoding [RFC5696] or 3-in-1 Encoding [I-D.ietf-pcn-3-in-1-encoding] 118 may be used to distinguish re-marked signaling packets from unmarked 119 signaling packets. 121 3. Edge Node Behaviours 123 This section explains the behavior of PCN-ingress-nodes and PCN- 124 egress-nodes. 126 3.1. Prerequisites 128 PCN-marked signaling assumes that admission control is triggered by a 129 signaling message at the PCN-ingress-node and that this signaling 130 message is carried across the PCN-domain to the PCN-egress-node on 131 the same path as future data packets of the associated flow. These 132 signaling messages are processed only by PCN-ingress-nodes and PCN- 133 egress-nodes. An example for such a signaling is the Resource 134 ReServation Protocol [RFC2205]. PCN-marked signaling is relatively 135 simple to implement when either PCN-ingress-node or PCN-egress-node 136 are involved in the signaling anyway. 138 3.2. Behavior of PCN-Ingress-Nodes 140 The PCN-ingress-node re-marks signaling messages to PCN not-marked 141 (NM) so that they are subject to metering and re-marking by PCN- 142 interior-nodes. Note that signaling packets need to be marked as PCN 143 not-marked (NM) only as long as the flow is not yet admitted. 145 In case of RSVP, the PCN-ingress-node performs the following non- 146 standard actions. If the PCN-ingress-node receives a PATH message, 147 it re-marks it to NM. If the PCN-ingress-node receives an initial 148 RESV message, it admits the flow for the hop over the PCN domain and 149 forwards the RESV message to the previous RSVP-hop on the path. 151 3.3. Behavior of PCN-Egress-Nodes 153 The PCN-egress-node detects signaling messages. As long as the flow 154 is not yet admitted, the PCN-egress-node evaluates the PCN codepoint 155 of received signaling messages. If the codepoint is NM, it takes 156 actions so that the flow can be admitted; otherwise it takes actions 157 so that the flow will be blocked. Finally, the PCN-egress-node 158 resets the PCN codepoint to not-PCN. 160 In case of RSVP, the PCN-egress-node performs the following non- 161 standard actions. If the PCN-egress-node receives an initial not- 162 marked PATH message, the PCN-egress-node forwards the message as 163 usual. If the PCN-egress-node receives an initial re-marked PATH 164 message, the PCN-egress-node drops the PATH message and returns a 165 PATH TEAR message to the previous RSVP hop indicating insufficient 166 resources. 168 4. IANA Considerations 170 This document makes no request to IANA. 172 5. Security Considerations 174 Please see the security considerations in [RFC2205], [RFC2474], and 175 [RFC2475]. [RFC5559] provides a general description of the security 176 considerations for PCN. 178 6. Conclusions 180 The PCN-based admission control method proposed in this document has 181 several benefits. It does not require any measurement and does not 182 require any parameters except for threshold metering and re-marking. 183 Implicit probing blocks very quickly as soon as pre-congestion occurs 184 [Menth08-Sub-8] and leads to less over-admission than PCN-based 185 admission control that calculates congestion level estimates per 186 ingress-egress aggregate to derive admission decisions. Moreover, 187 Implicit Probing works well with multipath routing when the signaling 188 message is carried on the same path as future data packets 189 [Menth08-Sub-8]. Admission control using PCN-marked signaling as 190 proposed in this document is simple provided that the admission of 191 flows is requested by a path-coupled signaling protocol (e.g. RSVP). 192 In contrast to other approaches [I-D.ietf-pcn-cl-edge-behaviour], 193 [I-D.ietf-pcn-sm-edge-behaviour] PCN-egress-nodes neither need to 194 measure PCN traffic nor need to signal PCN-feedback. In particular, 195 pcn-egress-nodes no longer need to map packets to corresponding 196 ingress-egress-aggregates. Moreover, the presented method blocks 197 very quickly as soon as pre-congestion occurs [Menth08-Sub-8], 198 minimizing over-admission. It also works well with multipath routing 199 if signaling messages are carried on the same path as future data 200 packets [Menth08-Sub-8], minimizing under-admission. 202 7. Acknowledgements 204 Joe Babiarz presented the idea documented in this memo for the first 205 time in [I-D.babiarz-pcn-3sm]. It was further developed to be useful 206 for restricted tunneling rules which called for a special encoding 207 [I-D.ietf-pcn-psdm-encoding], [I-D.menth-pcn-psdm-deployment], 208 [Menth09f]. 210 8. References 211 8.1. Normative References 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997. 216 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 217 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 218 Functional Specification", RFC 2205, September 1997. 220 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 221 "Definition of the Differentiated Services Field (DS 222 Field) in the IPv4 and IPv6 Headers", RFC 2474, 223 December 1998. 225 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 226 and W. Weiss, "An Architecture for Differentiated 227 Services", RFC 2475, December 1998. 229 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 230 Architecture", RFC 5559, June 2009. 232 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 233 Nodes", RFC 5670, November 2009. 235 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 236 Encoding and Transport of Pre-Congestion Information", 237 RFC 5696, November 2009. 239 8.2. Informative References 241 [I-D.babiarz-pcn-3sm] 242 Babiarz, J., Liu, X., Chan, K., and M. Menth, "Three State 243 PCN Marking", draft-babiarz-pcn-3sm-01 (work in progress), 244 November 2007. 246 [I-D.ietf-pcn-3-in-1-encoding] 247 Briscoe, B., Moncaster, T., and M. Menth, "Encoding 3 PCN- 248 States in the IP header using a single DSCP", 249 draft-ietf-pcn-3-in-1-encoding-04 (work in progress), 250 January 2011. 252 [I-D.ietf-pcn-cl-edge-behaviour] 253 Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. 254 Taylor, "PCN Boundary Node Behaviour for the Controlled 255 Load (CL) Mode of Operation", 256 draft-ietf-pcn-cl-edge-behaviour-08 (work in progress), 257 December 2010. 259 [I-D.ietf-pcn-psdm-encoding] 260 Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, 261 "PCN Encoding for Packet-Specific Dual Marking (PSDM 262 Encoding)", draft-ietf-pcn-psdm-encoding-01 (work in 263 progress), March 2010. 265 [I-D.ietf-pcn-sm-edge-behaviour] 266 Charny, A., Karagiannis, G., Menth, M., and T. Taylor, 267 "PCN Boundary Node Behaviour for the Single Marking (SM) 268 Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-05 269 (work in progress), December 2010. 271 [I-D.menth-pcn-psdm-deployment] 272 Menth, M., "Deployment Models for PCN-Based Admission 273 Control and Flow Termination Using Packet-Specific Dual 274 Marking (PSDM)", draft-menth-pcn-psdm-deployment-00 (work 275 in progress), October 2008. 277 [Menth08-Sub-8] 278 Menth, M. and F. Lehrieder, "Performance of PCN-Based 279 Admission Control", currently under submission, University 280 of Wuerzburg, Germany, 2011. 282 [Menth09f] 283 Menth, M., Babiarz, J., and P. Eardley, "Pre-Congestion 284 Notification Using Packet-Specific Dual Marking", 285 in Proceedings of the International Workshop on the 286 Network of the Future (Future-Net), IEEE, Dresden, 287 Germany, June 2009. 289 Authors' Addresses 291 Michael Menth 292 University of Tuebingen 293 Department of Computer Science 294 Chair of Communication Networks 295 Sand 13 296 Tuebingen 72076 297 Germany 299 Phone: +49 7071 29 70505 300 Email: menth@informatik.uni-tuebingen.de 301 Ruediger Geib 302 Deutsche Telekom 303 Heinrich-Hertz-Strasse 3-7 304 Darmstadt 64295 305 Germany 307 Phone: +49 6151 628 2747 308 Email: ruediger.geib@telekom.de