idnits 2.17.1 draft-ietf-pcn-signaling-requirements-01.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 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 (October 20, 2010) is 4936 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 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: April 20, 2011 K. Chan 5 Huawei Technologies 6 M. Menth 7 University of Wurzburg 8 October 20, 2010 10 Requirements for Signaling of (Pre-) Congestion Information in a 11 DiffServ Domain 12 draft-ietf-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 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). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 18, 2011. 43 Copyright Notice 44 Copyright (c) 2010 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 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Signaling Requirements between PCN-egress-nodes and 67 Decision Point . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1 PCN Reporting Frequency . . . . . . . . .. . . . . . . . . . . 4 69 2.2 Signaled PCN egress Feedback . . . . . . .. . . . . . . . . . .5 70 2.3 Signaling Requirements . . . . . . . . . .. . . . . . . . . . .6 71 2.3.1 Priority of Signaling Messages . . . . . . . . . . . . . . 6 72 2.3.2 Local Information Exchange. . . . . . . . . . . . . . . . .6 73 2.3.3 Carry Identification of PCN edge Nodes . . . . . . . . . .6 74 2.3.4 Carry Identification of ingress-egress-aggregates . . . . 6 75 2.3.5 Signaling Load. . . . . . .. . . . . . . . . . . . . . . . 6 76 2.3.6 Reliability. . . . . . .. . . . . . . . . . . . . . . . . 7 77 2.3.7 Security. . . . . . .. . . . . . . . . . . . . . . . . . 7 78 2.4. Filter Specifications . . . . . . . . . . . . . . . . . . . . 7 79 3. Signaling Requirements between Decision Point and 80 PCN-ingress-nodes . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.1 Signaled PCN ingress Feedback. . . . . . . . . . . . . . . . . 8 82 3.2 Signaled Decision Point Trigger. . . . . . . . . . . . . . . . 8 83 3.3 Signaling Requirements . . . . . . . . . .. . . . . . . . . . .8 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 8 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 9 89 7.2. Informative References . . . . . . . . . . . . . . . . . . . 9 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 92 1. Introduction 94 The main objective of Pre-Congestion Notification (PCN) is to support 95 the quality of service (QoS) of inelastic flows within a Diffserv 96 domain in a simple, scalable, and robust fashion. Two mechanisms 97 are used: admission control and flow termination. Admission control 98 is used to decide whether to admit or block a new flow request while 99 flow termination is used in abnormal circumstances to decide 100 whether to terminate some of the existing flows. To support these 101 two features, the overall rate of PCN-traffic is metered on every 102 link in the domain, and PCN-packets are appropriately marked when 103 certain configured rates are exceeded. These configured rates are 104 below the rate of the link thus providing notification to boundary 105 nodes about overloads before any congestion occurs (hence "pre- 106 congestion" notification). The PCN-egress-nodes measure the rates of 107 differently marked PCN traffic in periodic intervals and report these 108 rates as so-called PCN feedback to the decision points for admission 109 control and flow termination based on which they take their 110 decisions.The decision points may be collocated with the PCN-ingress- 111 nodes or their function may be implemented in a centralized node. 112 For more details see[RFC5559, [draft-ietf-pcn-cl-edge-behaviour-07], 113 [draft-ietf-pcn-sm-edge-behaviour-04]. 115 Thus, signaling is needed to transport PCN feedback from PCN-egress- 116 nodes towards the decision point. Moreover, signaling is needed that 117 the decision point can trigger the PCN-ingress-node to measure the 118 PCN traffic rate and send these measurement results to the decision 119 point. 121 This memo briefly describes the signaled content and specifies the 122 requirements that have to be satisfied by the signaling protocols. 124 1.1. Terminology 126 In addition to the terms defined in [RFC5559], this document uses the 127 following terms: 129 Decision Point: 131 The node that makes the decision about which flows to admit and to 132 terminate. In a given network deployment, this may be the ingress 133 node or a centralized control node. Of course, regardless of the 134 location of the decision point, the ingress node is the point 135 where the decisions are enforced. 137 PCN egress feedback: 139 Content used by the PCN-egress-node to report and inform the 140 decision point about measurements required during flow 141 admission and flow termination decisions. 143 PCN ingress feedback: 145 Content used by the PCN-ingress-node to report and inform the 146 decision point about measurements required during flow termination 147 decisions. 149 ingress rate request: 151 A message sent by the decision point towards the PCN-ingress-node 152 to request the PCN-ingress-node to measure and report the value of 153 the rate of admitted PCN traffic for a given 154 ingress-egress-aggregate. 156 Congestion level estimate (CLE) 157 A value derived from the measurement of PCN packets calculated at 158 A PCN-egress-node for a given ingress-egress-aggregate, 159 Representing the ratio of marked to total PCN traffic (measured in 160 octets) over a short period. For further details see 161 [draft-ietf-pcn-cl-edge-behaviour-07] and [draft-ietf-pcn-sm-edge- 162 behaviour-04]. 164 2. Signaling requirements between PCN-egress-nodes and 165 Decision Point 167 The PCN-egress-node measures the rates of differently marked PCN 168 traffic in regular intervals and signals them as PCN egress feedback 169 to the decision point. 170 This section describes the PCN egress feedback and the requirements 171 that apply to signaling protocols used for the transport of PCN 172 feedback from PCN-egress-nodes to decision points. 173 Note that if the decision point and the PCN-ingress-node are 174 collocated, then the signaling requirements described in this section 175 apply to the signaling between PCN-egress-nodes and PCN-ingress- 176 nodes. 178 2.1 PCN Reporting Frequency 180 The specification of PCN-based admission control and flow termination 181 in [draft-ietf-pcn-cl-edge-behaviour-07], [draft-ietf-pcn-sm-edge- 182 behaviour-04] suggest measurement and reporting intervals at the PCN- 183 egress-nodes of 100 to 500 ms. The PCN reporting frequency can 184 provide some level of reliability. Therefore, it is considered that 185 for regularly reported information, additional reliability mechanisms 186 are not needed, see Section 2.3.6. The following PCN contents are 187 sent regularly: rate of not-marked PCN traffic, rate of threshold- 188 marked PCN traffic, rate of excess-traffic-marked PCN traffic, CLE. 190 2.2 Signaled PCN egress Feedback 192 The PCN-egress-node measures per ingress-egress-aggregate the 193 following rates 194 o rate of not-marked PCN traffic; 195 o rate of threshold-marked PCN traffic, which applies to CL edge 196 behaviour only; 197 o rate of excess-traffic-marked PCN traffic. 198 o Congestion level estimate (CLE) 200 The rate values are reported in octets/second to the decision point 201 each time that the PCN-egress-node calculates them and when this is 202 supported via configuration. CLE is only reported to the decision 203 point when this is supported via configuration. 204 In particular (see [draft-ietf-pcn-cl-edge-behaviour-07], 205 [draft-ietf-pcn-sm-edge-behaviour-04]: 207 o) if the report suppression option is not activated, the PCN- 208 egress-node MUST report the latest values of rate of not-marked 209 PCN traffic, rate of threshold-marked PCN traffic and rate of 210 excess-traffic-marked PCN traffic, to the Decision Point each 211 time that it calculates them. 213 o) otherwise, if the report suppression option is activated, then 214 each PCN feedback report sent to the Decision Point MUST contain 215 the values of rate of not-marked PCN traffic, rate of threshold- 216 marked PCN traffic and rate of excess-traffic-marked PCN traffic 217 and CLE that were calculated for the most recent measurement 218 interval. 220 If so configured (e.g., because multipath routing is being used), the 221 PCN-egress-node MUST also include in the PCN feedback and report the 222 set of flow identifiers of PCN-flows for which excess-traffic-marking 223 was observed in the most recent measurement interval. 225 The representation of a flow ID depends on the surrounding 226 environment, e.g., "pure IP", MPLS, GMPLS, etc. Examples of such flow 227 ID representations can be found in [RFC2205], [RFC3175] [RFC3209], 228 [RFC3473]. The list SHOULD be a concatenation of flow IDs associated 229 with the flows that are candidates for termination. The format of a 230 list containing flow ID_1 to flow ID_n SHOULD be: 231 list flow IDs = ... . 232 If this set is large, the PCN-egress-node MAY report only the most 233 recently excess-traffic-marked PCN-flows rather than the complete 234 set. 236 For more details see [draft-ietf-pcn-cl-edge-behaviour-07], [draft- 237 ietf-pcn-sm-edge-behaviour-04]. 239 2.3 Signaling Requirements 241 This section describes the requirements for signaling protocols that 242 are used to carry the PCN egress feedback from PCN-egress-nodes to 243 the decision point. 245 2.3.1 Priority of Signaling Messages 247 Signaling messages SHOULD have a higher priority than data packets. 248 This is needed to avoid as much as possible the situations that 249 during severe overload cases the signaling messages are dropped 250 within the PCN domain. 252 2.3.2 Local Information Exchange 254 Signaling messages MUST be able to carry the PCN egress feedback from 255 the PCN-egress-node to the decision point. 257 2.3.3 Carry Identification of PCN edge Nodes 259 The signaling protocol MUST be able to carry identification 260 (address information) of the PCN edge nodes. 262 This is required due to the fact that the decision point needs to be 263 able to associate the received signaling message with the PCN edge 264 node that sent this message. 265 However, the identification of the PCN edge nodes 266 MUST NOT be visible to non-PCN nodes outside the PCN domain. 268 2.3.4 Carry Identification of ingress-egress-aggregates 270 The signaling protocol MUST be able to carry identification 271 (address information) of the ingress-egress-aggregates. It is 272 proposed to identify them using the addresses of the PCN-ingress-node 273 and PCN-egress-node between which they pass. If each of the edge 274 nodes do not have unique addresses, then other identifiers could be 275 used. 277 2.3.5 Signaling Load 279 The load generated by the signaling protocol to carry the PCN egress 280 Feedback from the PCN-egress-nodes to the decision point SHOULD be 281 minimized as much as possible. 283 2.3.6 Reliability 285 There are situations that messages need to be received in a 286 reliable way. There are different ways of achieving reliability. The 287 specification of a mandatory solution of achieving this reliability 288 is out of the scope of this document. It can be however considered, 289 that when information is received on a regular fashion, additional 290 reliability measures Should Not be required. 292 2.3.7 Security 294 The signaling support may need security protection against replay 295 attacks. The security services to be supported are: 296 o) Message authentication and integrity: an attacker could cause 297 denial of service using impersonation. Moreover, an attacker 298 could cause a denial of service by modifying message contents. 299 Therefore, message authentication and integrity SHOULD be 300 supported. 301 o) Message confidentiality: There could be situations where the PCN 302 signaling messages should not be visible to non authorised nodes. 303 In such cases, PCN message confidentiality MAY be supported. 305 2.4. Filter Specifications 307 In PCN the ingress and egress nodes should be able to identify the 308 ingress-egress-aggregate to which each flow belongs. 309 Moreover, the egress node also needs to associate an aggregate with 310 the address of the ingress node for receiving reports, if the ingress 311 node is the decision point.The filter specification at the PCN- 312 egress-nodes depends on the surrounding environment, e.g., pure IP, 313 MPLS, GMPLS. 314 In this document, a possible IP filter spec for pure IP is given as 315 an example. In this case the filter spec should be able to identify a 316 flow using (all or a subset of the) following information: 318 o source IP address; 320 o destination IP address; 322 o protocol identifier and higher layer (port) addressing; 324 o flow label (typical for IPv6); 326 o SPI field for IPsec encapsulated data; 328 o DSCP/TOS field. 330 o IP address of PCN-ingress-node 332 o IP address of PCN-egress-node 334 3. Signaling Requirements between Decision Point and PCN-ingress-nodes 336 The decision point monitors and uses the PCN egress feedback sent by 337 the PCN-egress-node. There are situations that the decision point 338 must obtain an estimate of the rate at which PCN-traffic is being 339 admitted to the aggregate from the PCN-ingress-node. 340 In order to receive this information the decision point has to 341 request from the PCN-ingress-node to send the value of the PCN 342 traffic admitted to a certain aggregate. 343 Note that if the decision point and the PCN-ingress-node are 344 collocated, then the information exchanges between the decision point 345 and PCN-ingress-node are internal operations. 347 3.1 Signaled PCN ingress Feedback 349 The PCN-ingress-node measures per ingress-egress-aggregate the 350 following rate 351 o rate of admitted PCN traffic 353 This value is reported in octets/second to the decision point as 354 soon as possible after receiving the request from the decision 355 point. . 357 3.2 Signaled Decision Point Trigger 359 The decision point uses the "ingress rate request" to request from 360 the PCN-ingress-node to send for a certain ingress-egress-aggregate, 361 the value of the admitted PCN traffic rate. 362 The "ingress rate request" message identifies the ingress-egress- 363 aggregate for which the admitted PCN traffic rate is required.The 364 only difference is the fact that these signaling requirements apply 365 for the signaling messages that have to be sent between the decision 366 point and PCN-ingress-nodes. Moreover, since the "ingress rate 367 request" message sent by the decision point towards the PCN-ingress- 368 node and the admitted PCN traffic rate sent by the PCN-ingress-node 369 towards the decision point are not sent regularly, they SHOULD be 370 delivered reliably. 372 3.3 Signaling Requirements 374 The same signaling requirements described in Section 2.3 apply for 375 this situation. 377 4. Security Considerations 379 [RFC5559] provides a general description of the security 380 considerations for PCN. This memo introduces the additional security 381 considerations described in Section 2.3.7. 383 5. IANA Considerations 385 This memo includes no request to IANA. 387 6. Acknowledgements 389 We would like to acknowledge the members of the PCN working group for 390 the discussions that generated the contents of this memo. 392 7. References 394 7.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 400 Architecture", RFC 5559, June 2009. 402 [draft-ietf-pcn-cl-edge-behaviour-07] T. Taylor, A, Charny, 403 F. Huang, G. Karagiannis, M. Menth, "PCN Boundary Node 404 Behaviour for the Controlled Load (CL) Mode of Operation 405 (Work in progress)", September 2010. 407 [draft-ietf-pcn-sm-edge-behaviour-04] A. Charny, J. Zhang, 408 G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node 409 Behaviour for the Single Marking (SM) Mode of Operation 410 (Work in progress)", September 2010. 412 7.2. Informative References 414 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 415 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 416 Functional Specification", RFC 2205, September 1997. 417 [RFC3175] Baker, F., Iturralde, C. Le Faucher, F., Davie, B., 418 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 419 RFC 3175, 2001. 421 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 422 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 423 Tunnels", RFC 3209, December 2001. 425 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 426 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 427 Engineering (RSVP-TE) Extensions", RFC 3473, 428 January 2003. 430 Authors' Addresses 432 Georgios Karagiannis 433 University of Twente 434 P.O. Box 217 435 7500 AE Enschede, 436 The Netherlands 437 EMail: g.karagiannis@ewi.utwente.nl 439 Tom Taylor 440 Huawei Technologies 441 1852 Lorraine Ave. 442 Ottawa, Ontario K1H 6Z8 443 Canada 444 Phone: +1 613 680 2675 445 Email: tom111.taylor@bell.net 447 Kwok Ho Chan 448 Huawei Technologies 449 125 Nagog Park 450 Acton, MA 01720 451 USA 452 Email: khchan@huawei.com 454 Michael Menth 455 University of Wurzburg 456 Institute of Computer Science 457 Room B206 458 Am Hubland, Wuerzburg D-97074 459 Germany 460 Email: menth@informatik.uni-wuerzburg.de