idnits 2.17.1 draft-karagiannis-pcn-signaling-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 date (March 8, 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force G. Karagiannis 2 Internet-Draft University of Twente 3 Intended status: Informational T. Taylor 4 Expires: September 8, 2010 K. Chan 5 Huawei Technologies 6 M. Menth 7 University of Wurzburg 8 March 8, 2010 10 Requirements for Signaling of (Pre-) Congestion Information in a 11 DiffServ Domain 12 draft-karagiannis-pcn-signaling-requirements-01 14 Abstract 16 Precongestion notification (PCN) is a means for protecting quality of 17 service for inelastic traffic admitted to a Diffserv domain. The 18 overall PCN architecture is described in RFC 5559. This memo 19 describes the requirements for the signaling applied within the PCN 20 domain: PCN feedback is carried from the PCN-egress-node to the 21 decision point and the decision point may demand for the measurement 22 and delivery of the PCN rate sent at the PCN-ingress-node. The 23 decision point may be either collocated with the PCN-ingress-node or 24 a centralized node. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 8, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Requirements Language 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [RFC2119]. 70 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Signaling requirements between PCN-egress-nodes and 74 Decision Point . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.1 PCN Reporting Frequency . . . . . . . . .. . . . . . . . . . . 4 76 2.2 Signaled PCN egress Feedback . . . . . . .. . . . . . . . . . .4 77 2.3 Signaling requirements . . . . . . . . . .. . . . . . . . . . .5 78 2.3.1 Priority of signaling messages . . . . . . . . . . . . . . 5 79 2.3.2 Local information exchange. . . . . . . . . . . . . . . . .5 80 2.3.3 Carry identification of PCN edge nodes . . . . . . . . . .5 81 2.3.4 Carry identification of ingress-egress-aggregates . . . . 5 82 2.3.5 Signaling load. . . . . . .. . . . . . . . . . . . . . . . 6 83 2.3.6 Reliability. . . . . . .. . . . . . . . . . . . . . . . . 6 84 2.4. Filter specifications . . . . . . . . . . . . . . . . . . . . 6 85 3. Signaling Requirements between Decision Point and 86 PCN-ingress-nodes . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 3.1 Signaled PCN ingress Feedback. . . . . . . . . . . . . . . . . 7 88 3.2 Signaled decision point trigger. . . . . . . . . . . . . . . . 7 89 3.3 Signaling requirements . . . . . . . . . .. . . . . . . . . . .7 90 4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 8 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 8 92 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 94 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 8 95 7.2. Informative References . . . . . . . . . . . . . . . . . . . 8 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 98 1. Introduction 100 The main objective of Pre-Congestion Notification (PCN) is to support 101 the quality of service (QoS) of inelastic flows within a Diffserv 102 domain in a simple, scalable, and robust fashion. Two mechanisms 103 are used: admission control and flow termination. Admission control 104 is used to decide whether to admit or block a new flow request while 105 flow termination is used in abnormal circumstances to decide 106 whether to terminate some of the existing flows. To support these 107 two features, the overall rate of PCN-traffic is metered on every 108 link in the domain, and PCN-packets are appropriately marked when 109 certain configured rates are exceeded. These configured rates are 110 below the rate of the link thus providing notification to boundary 111 nodes about overloads before any congestion occurs (hence "pre- 112 congestion" notification). The PCN-egress-nodes measure the rates of 113 differently marked PCN traffic in periodic intervals and report these 114 rates as so-called PCN feedback to the decision points for admission 115 control and flow termination based on which they take their 116 decisions.The decision points may be collocated with the PCN-ingress- 117 nodes or their function may be implemented in a centralized node. 119 For more details see[RFC5559, [draft-ietf-pcn-cl-edge-behaviour-02], 120 [draft-ietf-pcn-sm-edge-behaviour-02]. 122 Thus, signaling is needed to transport PCN feedback from PCN-egress- 123 nodes towards the decision point. Moreover, signaling is needed that 124 the decision point can trigger the PCN-ingress-node to measure the 125 PCN traffic rate and send these measurement results to the decision 126 point. 128 This memo briefly describes the signaled content and specifies the 129 requirements that have to be satisfied by the signaling protocols. 131 1.1. Terminology 133 In addition to the terms defined in [RFC5559], this document uses the 134 following terms: 136 Decision Point: 138 The node that makes the decision about which flows to admit and to 139 terminate. In a given network deployment, this may be the ingress 140 node or a centralized control node. Of course, regardless of the 141 location of the decision point, the ingress node is the point 142 where the decisions are enforced. 144 PCN egress feedback: 146 Content used by the PCN-egress-node to report and inform the 147 decision point about measurements required during flow 148 admission and flow termination decisions. 150 PCN ingress feedback: 152 Content used by the PCN-ingress-node to report and inform the 153 decision point about measurements required during flow termination 154 decisions. 156 ingress rate request: 158 A message sent by the decision point towards the PCN-ingress-node 159 to request the PCN-ingress-node to measure and report the value of 160 the rate of admitted PCN traffic for a given 161 ingress-egress-aggregate. 163 2. Signaling requirements between PCN-egress-nodes and 164 Decision Point 166 The PCN-egress-node measures the rates of differently marked PCN 167 traffic in regular intervals and signals them as PCN egress feedback 168 to the decision point. 169 This section describes the PCN egress feedback and the requirements 170 that apply to signaling protocols used for the transport of PCN 171 feedback from PCN-egress-nodes to decision points. 172 Note that if the decision point and the PCN-ingress-node are 173 collocated, then the signaling requirements described in this section 174 apply to the signaling between PCN-egress-nodes and PCN-ingress- 175 nodes. 177 2.1 PCN Reporting Frequency 179 The specification of PCN-based admission control and flow termination 180 in [draft-ietf-pcn-cl-edge-behaviour-02], [draft-ietf-pcn-sm-edge- 181 behaviour-02] suggest measurement and reporting intervals at the PCN- 182 egress-nodes of 100 to 500 ms. 184 2.2 Signaled PCN egress Feedback 186 The PCN-egress-node measures per ingress-egress-aggregate the 187 following rates 188 o rate of not-marked PCN traffic; 189 o rate of threshold-marked PCN traffic, which applies to CL edge 190 behaviour only; 191 o rate of excess-traffic-marked PCN traffic. 193 These values are reported in octets/second to the decision point at 194 the end of each measurement interval. 196 If multipath routing is enabled, the PCN-egress-node tracks a list of 197 flows for which it has recently received excess-traffic-marked 198 packets. The list of these flow IDs is included in the PCN feedback 199 because these flows are candidates for termination. 200 The representation of a flow ID depends on the surrounding 201 environment, e.g., "pure IP", MPLS, GMPLS, etc. For the 202 representation of a flow ID in a "pure IP" surrounding environment, 203 see Section 2.4. 205 2.3 Signaling requirements 207 This section describes the requirements for signaling protocols that 208 are used to carry the PCN egress feedback from PCN-egress-nodes to 209 the decision point. 211 2.3.1 Priority of signaling messages 213 Signaling messages SHOULD have a higher priority than data packets. 214 This is needed to avoid as much as possible the situations that 215 during severe overload cases the signaling messages are dropped 216 within the PCN domain. 218 2.3.2 Local information exchange 220 Signaling messages MUST be able to carry the PCN egress feedback from 221 the PCN-egress-node to the decision point. 223 2.3.3 Carry identification of PCN edge nodes 225 The signaling protocol MUST be able to carry identification 226 (address information) of the PCN edge nodes. 227 However, the identification of the PCN edge nodes 228 MUST NOT be visible outside the PCN domain. 230 2.3.4 Carry identification of ingress-egress-aggregates 232 The signaling protocol MUST be able to carry identification 233 (address information) of the ingress-egress-aggregates. It is 234 proposed to identify them using the addresses of the PCN-ingress-node 235 and PCN-egress-node between which they pass. If each of the edge 236 nodes do not have unique addresses, then other identifiers could be 237 used. 239 2.3.5 Signaling load 241 The load generated by the signaling protocol to carry the PCN egress 242 Feedback from the PCN-egress-nodes to the decision point SHOULD be 243 minimized as much as possible. 245 2.3.6 Reliability 247 There are situations that messages need to be sent in a 248 reliable way, meaning that the PCN-egress-node MUST be acknowledged 249 that the sent message is successfully received by the 250 decision point. It is considered that the PCN egress feedback that 251 is sent in a regular fashion SHOULD NOT be sent reliably. 253 2.4. Filter specifications 255 In PCN the ingress and egress nodes should be able to identify the 256 ingress-egress-aggregate to which each flow belongs. Moreover, the 257 egress node also needs to associate an aggregate with the address of 258 the ingress node for receiving reports, if the ingress node is the 259 decision point. The filter specification at the PCN-egress-nodes 260 depends on the surrounding environment, e.g., pure IP, MPLS, GMPLS. 261 In this document, only the pure IP filter spec is given as an 262 example. In this case the filter spec should be able to identify a 263 flow using (all or a subset of the) following information: 265 o source IP address; 267 o destination IP address; 269 o protocol identifier and higher layer (port) addressing; 271 o flow label (typical for IPv6); 273 o SPI field for IPsec encapsulated data; 275 o DSCP/TOS field. 277 o IP address of PCN-ingress-node 279 o IP address of PCN-egress-node 281 o IP address of decision point 283 3. Signaling Requirements between Decision Point and PCN-ingress-nodes 285 The decision point monitors and uses the PCN egress feedback sent by 286 the PCN-egress-node. There are situations that the decision point 287 must obtain an estimate of the rate at which PCN-traffic is being 288 admitted to the aggregate from the PCN-ingress-node. 289 In order to receive this information the decision point has to 290 request from the PCN-ingress-node to send the value of the PCN 291 traffic admitted to a certain aggregate. 292 Note that if the decision point and the PCN-ingress-node are 293 collocated, then the signaling required between the decision point 294 and PCN-ingress-node are internal operations. 296 3.1 Signaled PCN ingress Feedback 298 The PCN-ingress-node measures per ingress-egress-aggregate the 299 following rate 300 o rate of admitted PCN traffic 302 This value is reported in octets/second to the decision point as 303 soon as possible after receiving the request from the decision 304 point. . 306 3.2 Signaled decision point trigger 308 The decision point uses the "ingress rate request" to request from 309 the PCN-ingress-node to send for a certain ingress-egress-aggregate, 310 the value of the admitted PCN traffic rate. The "ingress rate 311 request" message identifies the ingress-egress-aggregate for which 312 the admitted PCN traffic rate is required. 314 3.3 Signaling requirements 316 The same signaling requirements described in Section 2.3 apply for 317 this situation. The only difference is the fact that these signaling 318 requirements apply for the signaling messages that have to be sent 319 between the decision point and PCN-ingress-nodes. Moreover, since the 320 "ingress rate request" message sent by the decision point towards 321 the PCN-ingress-node and the admitted PCN traffic rate sent by the 322 PCN-ingress-node towards the decision point are not sent regularly, 323 they SHOULD be delivered reliably. 325 4. Security Considerations 327 [RFC5559] provides a general description of the security 328 considerations for PCN. This memo introduces no new considerations. 330 5. IANA Considerations 332 This memo includes no request to IANA. 334 6. Acknowledgements 336 We would like to acknowledge the members of the PCN working group for 337 the discussions that generated the contents of this memo. 339 7. References 341 7.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 347 Architecture", RFC 5559, June 2009. 349 [draft-ietf-pcn-cl-edge-behaviour-02] T. Taylor, A, Charny, 350 F. Huang, G. Karagiannis, M. Menth, "PCN Boundary Node 351 Behaviour for the Controlled Load (CL) Mode of Operation 352 (Work in progress)", March 2010. 354 [draft-ietf-pcn-sm-edge-behaviour-02] A. Charny, J. Zhang, 355 G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node 356 Behaviour for the Single Marking (SM) Mode of Operation 357 (Work in progress)", March 2010. 359 7.2. Informative References 360 Authors' Addresses 362 Georgios Karagiannis 363 University of Twente 364 P.O. Box 217 365 7500 AE Enschede, 366 The Netherlands 367 EMail: g.karagiannis@ewi.utwente.nl 369 Tom Taylor 370 Huawei Technologies 371 1852 Lorraine Ave. 372 Ottawa, Ontario K1H 6Z8 373 Canada 374 Phone: +1 613 680 2675 375 Email: tom111.taylor@bell.net 377 Kwok Ho Chan 378 Huawei Technologies 379 125 Nagog Park 380 Acton, MA 01720 381 USA 382 Email: khchan@huawei.com 384 Michael Menth 385 University of Wurzburg 386 Institute of Computer Science 387 Room B206 388 Am Hubland, Wuerzburg D-97074 389 Germany 390 Email: menth@informatik.uni-wuerzburg.de