idnits 2.17.1 draft-ietf-pcn-signaling-requirements-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 64 lines == 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 : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2010) is 5041 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 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: January 5, 2011 K. Chan 5 Huawei Technologies 6 M. Menth 7 University of Wurzburg 8 July 5, 2010 10 Requirements for Signaling of (Pre-) Congestion Information in a 11 DiffServ Domain 12 draft-ietf-pcn-signaling-requirements-00 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 January 5, 2011. 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 . . . . . . .. . . . . . . . . . .5 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 . . . . 6 82 2.3.5 Signaling load. . . . . . .. . . . . . . . . . . . . . . . 6 83 2.3.6 Reliability. . . . . . .. . . . . . . . . . . . . . . . . 6 84 2.3.7 Security. . . . . . .. . . . . . . . . . . . . . . . . . 6 85 2.4. Filter specifications . . . . . . . . . . . . . . . . . . . . 6 86 3. Signaling Requirements between Decision Point and 87 PCN-ingress-nodes . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 3.1 Signaled PCN ingress Feedback. . . . . . . . . . . . . . . . . 7 89 3.2 Signaled decision point trigger. . . . . . . . . . . . . . . . 7 90 3.3 Signaling requirements . . . . . . . . . .. . . . . . . . . . .7 91 4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 8 92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 8 93 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 95 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 8 96 7.2. Informative References . . . . . . . . . . . . . . . . . . . 8 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 99 1. Introduction 101 The main objective of Pre-Congestion Notification (PCN) is to support 102 the quality of service (QoS) of inelastic flows within a Diffserv 103 domain in a simple, scalable, and robust fashion. Two mechanisms 104 are used: admission control and flow termination. Admission control 105 is used to decide whether to admit or block a new flow request while 106 flow termination is used in abnormal circumstances to decide 107 whether to terminate some of the existing flows. To support these 108 two features, the overall rate of PCN-traffic is metered on every 109 link in the domain, and PCN-packets are appropriately marked when 110 certain configured rates are exceeded. These configured rates are 111 below the rate of the link thus providing notification to boundary 112 nodes about overloads before any congestion occurs (hence "pre- 113 congestion" notification). The PCN-egress-nodes measure the rates of 114 differently marked PCN traffic in periodic intervals and report these 115 rates as so-called PCN feedback to the decision points for admission 116 control and flow termination based on which they take their 117 decisions.The decision points may be collocated with the PCN-ingress- 118 nodes or their function may be implemented in a centralized node. 120 For more details see[RFC5559, [draft-ietf-pcn-cl-edge-behaviour-06], 121 [draft-ietf-pcn-sm-edge-behaviour-03]. 123 Thus, signaling is needed to transport PCN feedback from PCN-egress- 124 nodes towards the decision point. Moreover, signaling is needed that 125 the decision point can trigger the PCN-ingress-node to measure the 126 PCN traffic rate and send these measurement results to the decision 127 point. 129 This memo briefly describes the signaled content and specifies the 130 requirements that have to be satisfied by the signaling protocols. 132 1.1. Terminology 134 In addition to the terms defined in [RFC5559], this document uses the 135 following terms: 137 Decision Point: 139 The node that makes the decision about which flows to admit and to 140 terminate. In a given network deployment, this may be the ingress 141 node or a centralized control node. Of course, regardless of the 142 location of the decision point, the ingress node is the point 143 where the decisions are enforced. 145 PCN egress feedback: 147 Content used by the PCN-egress-node to report and inform the 148 decision point about measurements required during flow 149 admission and flow termination decisions. 151 PCN ingress feedback: 153 Content used by the PCN-ingress-node to report and inform the 154 decision point about measurements required during flow termination 155 decisions. 157 ingress rate request: 159 A message sent by the decision point towards the PCN-ingress-node 160 to request the PCN-ingress-node to measure and report the value of 161 the rate of admitted PCN traffic for a given 162 ingress-egress-aggregate. 164 Congestion level estimate (CLE) 165 A value derived from the measurement of PCN packets calculated at a 166 PCN-egress-node for a given ingress-egress-aggregate, representing 167 the ratio of marked to total PCN traffic (measured in octets) over 168 a short period. For further details see 169 [draft-ietf-pcn-cl-edge-behaviour-06] and [draft-ietf-pcn-sm-edge- 170 behaviour-03]. 172 2. Signaling requirements between PCN-egress-nodes and 173 Decision Point 175 The PCN-egress-node measures the rates of differently marked PCN 176 traffic in regular intervals and signals them as PCN egress feedback 177 to the decision point. 178 This section describes the PCN egress feedback and the requirements 179 that apply to signaling protocols used for the transport of PCN 180 feedback from PCN-egress-nodes to decision points. 181 Note that if the decision point and the PCN-ingress-node are 182 collocated, then the signaling requirements described in this section 183 apply to the signaling between PCN-egress-nodes and PCN-ingress- 184 nodes. 186 2.1 PCN Reporting Frequency 188 The specification of PCN-based admission control and flow termination 189 in [draft-ietf-pcn-cl-edge-behaviour-06], [draft-ietf-pcn-sm-edge- 190 behaviour-03] suggest measurement and reporting intervals at the PCN- 191 egress-nodes of 100 to 500 ms. The PCN reporting frequency can provide 192 some level of reliability. Therefore, it is considered that for regularly 193 reported information, additional reliability mechanisms are not needed, 194 see Section 2.3.6. The following PCN contents are sent regularly: rate of 195 not-marked PCN traffic, rate of threshold-marked PCN 196 traffic, rate of excess-traffic-marked PCN traffic, CLE. 198 2.2 Signaled PCN egress Feedback 200 The PCN-egress-node measures per ingress-egress-aggregate the 201 following rates 202 o rate of not-marked PCN traffic; 203 o rate of threshold-marked PCN traffic, which applies to CL edge 204 behaviour only; 205 o rate of excess-traffic-marked PCN traffic. 206 o Congestion level estimate (CLE) 208 The rate values are reported in octets/second to the decision point each 209 time that the PCN-egress-node calculates them and when this is supported 210 via configuration. CLE is only reported to the decision point when this 211 is supported via configuration. 212 For more details see [draft-ietf-pcn-cl-edge-behaviour-06], [draft-ietf- 213 pcn-sm-edge-behaviour-03]. 215 If multipath routing is enabled, the PCN-egress-node tracks a list of 216 flows for which it has recently received excess-traffic-marked 217 packets. The list of these flow IDs is included in the PCN feedback 218 because these flows are candidates for termination. 219 The representation of a flow ID depends on the surrounding 220 environment, e.g., "pure IP", MPLS, GMPLS, etc. Examples of such flow ID 221 representations can be found in [RFC2205], [RFC3175] [RFC3209], 222 [RFC3473]. The list SHOULD be a concatenation of flow IDs associated with 223 the flows that are candidates for termination. The format of a list 224 containing flow ID_1 to flow ID_n SHOULD be: 225 list flow IDs = ... . 227 2.3 Signaling requirements 229 This section describes the requirements for signaling protocols that 230 are used to carry the PCN egress feedback from PCN-egress-nodes to 231 the decision point. 233 2.3.1 Priority of signaling messages 235 Signaling messages SHOULD have a higher priority than data packets. 236 This is needed to avoid as much as possible the situations that 237 during severe overload cases the signaling messages are dropped 238 within the PCN domain. 240 2.3.2 Local information exchange 242 Signaling messages MUST be able to carry the PCN egress feedback from 243 the PCN-egress-node to the decision point. 245 2.3.3 Carry identification of PCN edge nodes 247 The signaling protocol MUST be able to carry identification 248 (address information) of the PCN edge nodes. This is required due to the 249 fact that the decision point needs to be able to associate the received 250 signaling message with the PCN edge node that sent this message. 252 However, the identification of the PCN edge nodes 253 MUST NOT be visible to non-PCN nodes outside the PCN domain. 255 2.3.4 Carry identification of ingress-egress-aggregates 257 The signaling protocol MUST be able to carry identification 258 (address information) of the ingress-egress-aggregates. It is 259 proposed to identify them using the addresses of the PCN-ingress-node 260 and PCN-egress-node between which they pass. If each of the edge 261 nodes do not have unique addresses, then other identifiers could be 262 used. 264 2.3.5 Signaling load 266 The load generated by the signaling protocol to carry the PCN egress 267 Feedback from the PCN-egress-nodes to the decision point SHOULD be 268 minimized as much as possible. 270 2.3.6 Reliability 272 There are situations that messages need to be received in a 273 reliable way. There are different ways of achieving reliability. The 274 solution of achieving this reliability is out of the scope of this 275 document. However, it is considered that when information is received on 276 a regular fashion, additional reliability measures are not 277 required. The list with flow IDs associated with the excess-traffic- 278 marked flows is not sent regularly, hence SHOULD be sent reliably. 280 2.3.7 Security 282 The signaling support may need security protection against replay 283 attacks. The security services to be supported are: 284 o) Message authentication and integrity: an attacker could cause denial 285 of service using impersonation. Moreover, an attacker could cause a 286 denial of service by modifying message contents. Therefore, message 287 authentication and integrity SHOULD be supported. 288 o) Message confidentiality: There could be situations where the PCN 289 signaling messages should not be visible to non authorised nodes. In 290 such cases, PCN message confidentiality MAY be supported. 292 2.4. Filter specifications 294 In PCN the ingress and egress nodes should be able to identify the 295 ingress-egress-aggregate to which each flow belongs. Moreover, the 296 egress node also needs to associate an aggregate with the address of 297 the ingress node for receiving reports, if the ingress node is the 298 decision point. The filter specification at the PCN-egress-nodes 299 depends on the surrounding environment, e.g., pure IP, MPLS, GMPLS. 301 In this document, a possible IP filter spec for pure IP is given as an 302 example. In this case the filter spec should be able to identify a 303 flow using (all or a subset of the) following information: 305 o source IP address; 307 o destination IP address; 309 o protocol identifier and higher layer (port) addressing; 311 o flow label (typical for IPv6); 313 o SPI field for IPsec encapsulated data; 315 o DSCP/TOS field. 317 o IP address of PCN-ingress-node 319 o IP address of PCN-egress-node 321 3. Signaling Requirements between Decision Point and PCN-ingress-nodes 323 The decision point monitors and uses the PCN egress feedback sent by 324 the PCN-egress-node. There are situations that the decision point 325 must obtain an estimate of the rate at which PCN-traffic is being 326 admitted to the aggregate from the PCN-ingress-node. 327 In order to receive this information the decision point has to 328 request from the PCN-ingress-node to send the value of the PCN 329 traffic admitted to a certain aggregate. 330 Note that if the decision point and the PCN-ingress-node are 331 collocated, then the information exchanges between the decision point 332 and PCN-ingress-node are internal operations. 334 3.1 Signaled PCN ingress Feedback 336 The PCN-ingress-node measures per ingress-egress-aggregate the 337 following rate 338 o rate of admitted PCN traffic 340 This value is reported in octets/second to the decision point as 341 soon as possible after receiving the request from the decision 342 point. . 344 3.2 Signaled decision point trigger 346 The decision point uses the "ingress rate request" to request from 347 the PCN-ingress-node to send for a certain ingress-egress-aggregate, 348 the value of the admitted PCN traffic rate. The "ingress rate 349 request" message identifies the ingress-egress-aggregate for which 350 the admitted PCN traffic rate is required. 352 3.3 Signaling requirements 354 The same signaling requirements described in Section 2.3 apply for 355 this situation. 357 The only difference is the fact that these signaling 358 requirements apply for the signaling messages that have to be sent 359 between the decision point and PCN-ingress-nodes. Moreover, since the 360 "ingress rate request" message sent by the decision point towards 361 the PCN-ingress-node and the admitted PCN traffic rate sent by the 362 PCN-ingress-node towards the decision point are not sent regularly, 363 they SHOULD be delivered reliably. 365 4. Security Considerations 367 [RFC5559] provides a general description of the security 368 considerations for PCN. This memo introduces the additional security 369 considerations described in Section 2.3.7. 371 5. IANA Considerations 373 This memo includes no request to IANA. 375 6. Acknowledgements 377 We would like to acknowledge the members of the PCN working group for 378 the discussions that generated the contents of this memo. 380 7. References 382 7.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 388 Architecture", RFC 5559, June 2009. 390 [draft-ietf-pcn-cl-edge-behaviour-06] T. Taylor, A, Charny, 391 F. Huang, G. Karagiannis, M. Menth, "PCN Boundary Node 392 Behaviour for the Controlled Load (CL) Mode of Operation 393 (Work in progress)", June 2010. 395 [draft-ietf-pcn-sm-edge-behaviour-03] A. Charny, J. Zhang, 396 G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node 397 Behaviour for the Single Marking (SM) Mode of Operation 398 (Work in progress)", June 2010. 400 7.2. Informative References 402 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 403 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 404 Functional Specification", RFC 2205, September 1997. 406 [RFC3175] Baker, F., Iturralde, C. Le Faucher, F., Davie, B., 407 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 408 RFC 3175, 2001. 410 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 411 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 412 Tunnels", RFC 3209, December 2001. 414 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 415 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 416 Engineering (RSVP-TE) Extensions", RFC 3473, 417 January 2003. 419 Authors' Addresses 421 Georgios Karagiannis 422 University of Twente 423 P.O. Box 217 424 7500 AE Enschede, 425 The Netherlands 426 EMail: g.karagiannis@ewi.utwente.nl 428 Tom Taylor 429 Huawei Technologies 430 1852 Lorraine Ave. 431 Ottawa, Ontario K1H 6Z8 432 Canada 433 Phone: +1 613 680 2675 434 Email: tom111.taylor@bell.net 436 Kwok Ho Chan 437 Huawei Technologies 438 125 Nagog Park 439 Acton, MA 01720 440 USA 441 Email: khchan@huawei.com 443 Michael Menth 444 University of Wurzburg 445 Institute of Computer Science 446 Room B206 447 Am Hubland, Wuerzburg D-97074 448 Germany 449 Email: menth@informatik.uni-wuerzburg.de