idnits 2.17.1 draft-ietf-pcn-signaling-requirements-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 8) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 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 02, 2011) is 4803 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 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: September 02, 2011 K. Chan 5 Huawei Technologies 6 M. Menth 7 University of Tuebingen 8 March 02, 2011 10 Requirements for Signaling of (Pre-) Congestion Information in a 11 DiffServ Domain 12 draft-ietf-pcn-signaling-requirements-02 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: (1) PCN feedback is carried from the PCN-egress-node to the 21 decision point;(2) 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 September 02, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Requirements Language 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [RFC2119]. 67 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Signaling Requirements between PCN-egress-nodes and 71 Decision Point . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1 Reporting Frequency . . . . . . . . .. . . . . . . . . . . . . 4 73 2.2 Reporting Information. . . . . . .. . . . . . . . . . . . . . 5 74 2.2.1 PCN egress Feedback . . . . . . .. . . . . . . . . . . . . .5 75 2.3 Signaling Requirements . . . . . . . . . .. . . . . . . . . . .5 76 2.3.1 Priority of Signaling Messages . . . . . . . . . . . . . . 6 77 2.3.2 Local Information Exchange. . . . . . . . . . . . . . . . .6 78 2.3.3 Carry Identification of PCN edge Nodes . . . . . . . . . .6 79 2.3.4 Carry Identification of ingress-egress-aggregates . . . . 6 80 2.3.5 Signaling Load. . . . . . .. . . . . . . . . . . . . . . . 6 81 2.3.6 Reliability. . . . . . .. . . . . . . . . . . . . . . . . 6 82 2.3.7 Security. . . . . . .. . . . . . . . . . . . . . . . . . 6 83 2.4. Filter Specifications . . . . . . . . . . . . . . . . . . . . 7 84 3. Signaling Requirements between Decision Point and 85 PCN-ingress-nodes . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 3.1 Reporting Frequency . . . . . . . . .. . . . . . . . . . . . . 7 87 3.2 Reporting Information . . . . . . . . . . . . . . . . . . . . .8 88 3.2.1 PCN ingress Feedback. . . . . . . . . . . . . . . . . . . . .8 89 3.2.2 Decision Point Trigger. . . . . . . . . . . . . . . . . . . .8 90 3.3 Signaling Requirements . . . . . . . . . .. . . . . . . . . . .8 91 3.3.1 Priority of Signaling Messages . . . . . . . . . . . . . . 8 92 3.3.2 Local Information Exchange. . . . . . . . . . . . . . . . .8 93 3.3.3 Carry Identification of PCN edge Nodes and Decision Point .8 94 3.3.4 Carry Identification of ingress-egress-aggregates . . . . 8 95 3.3.5 Signaling Load. . . . . . .. . . . . . . . . . . . . . . . 9 96 3.3.6 Reliability. . . . . . .. . . . . . . . . . . . . . . . . 9 97 3.3.7 Security. . . . . . .. . . . . . . . . . . . . . . . . . 9 98 4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 9 99 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 100 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 102 7.1. Normative References . . . . . . . . . . . . . . . . . . . .10 103 7.2. Informative References . . . . . . . . . . . . . . . . . . .10 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 106 1. Introduction 108 The main objective of Pre-Congestion Notification (PCN) is to support 109 the quality of service (QoS) of inelastic flows within a Diffserv 110 domain in a simple, scalable, and robust fashion. Two mechanisms 111 are used: admission control and flow termination. Admission control 112 is used to decide whether to admit or block a new flow request while 113 flow termination is used in abnormal circumstances to decide 114 whether to terminate some of the existing flows. To support these 115 two features, the overall rate of PCN-traffic is metered on every 116 link in the domain, and PCN-packets are appropriately marked when 117 certain configured rates are exceeded. These configured rates are 118 below the rate of the link thus providing notification to boundary 119 nodes about overloads before any congestion occurs (hence "pre- 120 congestion" notification). The PCN-egress-nodes measure the rates of 121 differently marked PCN traffic in periodic intervals and report these 122 rates as so-called PCN feedback to the decision points for admission 123 control and flow termination based on which they take their 124 decisions. The decision points may be collocated with the PCN- 125 ingress-nodes or their function may be implemented in a centralized 126 node. 127 For more details see[RFC5559, [draft-ietf-pcn-cl-edge-behaviour-08], 128 [draft-ietf-pcn-sm-edge-behaviour-05]. 130 This memo specifies the requirements that have to be satisfied by the 131 signaling protocols needed to transport: 133 o PCN egress feedback, from a PCN-egress-node to the decision point; 134 o a request, from the decision point to a PCN-ingress-node, that 135 triggers the PCN-ingress-node to measure the PCN-sent-rate; 136 o PCN ingress feedback, from a PCN-ingress-node to the decision 137 point. 139 A signaling message may either be sent directly, or may piggy-backed 140 on some other message that is being sent via the relevant node. 142 1.1. Terminology 144 In addition to the terms defined in [RFC5559], [draft-ietf-pcn-cl- 145 edge-behaviour-08] and [draft-ietf-pcn-sm-edge-behaviour-05], 146 this document uses the following terms: 148 PCN egress feedback: 150 A report sent by the PCN-egress-node to the decision point. It 151 reports measurements made by the PCN-egress-node that inform 152 decisions about flow admission and flow termination. 154 PCN ingress feedback: 156 A report sent by the PCN-ingress-node to the decision point. It 157 reports: 158 o measurements made by the PCN-ingress-node that inform 159 decisions about flow termination; 160 o measurements of the PCN-sent-rate. 162 2. Signaling requirements between PCN-egress-nodes and 163 Decision Point 165 The PCN-egress-node measures the rates of differently marked PCN 166 traffic in regular intervals and signals them as PCN egress feedback 167 to the decision point. 168 This section describes the PCN egress feedback and the requirements 169 that apply to signaling protocols used for the transport of PCN 170 feedback from PCN-egress-nodes to decision points. 171 Note that if the decision point and the PCN-ingress-node are 172 collocated, then the signaling requirements described in this section 173 apply to the signaling between PCN-egress-nodes and PCN-ingress- 174 nodes. 176 2.1 Reporting Frequency 178 The specification of PCN-based admission control and flow termination 179 in [draft-ietf-pcn-cl-edge-behaviour-08], [draft-ietf-pcn-sm-edge- 180 behaviour-04] suggest measurement and reporting intervals at the PCN- 181 egress-nodes of 100 to 500 ms. The PCN reporting frequency can 182 provide some level of reliability. Therefore, it is considered that 183 for regularly reported information, additional reliability mechanisms 184 are not needed, see Section 2.3.6. 186 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 Reporting Information 192 This section briefly describes the information that is reported by 193 the PCN-egress-node. 195 2.2.1 PCN egress Feedback 197 The PCN-egress-node measures per ingress-egress-aggregate the 198 following rates 199 o rate of not-marked PCN traffic; 200 o rate of threshold-marked PCN traffic, which applies to CL edge 201 behavior only; 202 o rate of excess-traffic-marked PCN traffic; 203 o Congestion level estimate (CLE) 205 The rate values are reported in octets/second to the decision point 206 each time that the PCN-egress-node calculates them and when this is 207 supported via configuration. 208 A report may either be sent periodically, every time the PCN-egress- 209 node measures the various rates, or else may be sent occasionally, 210 see "optional report suppression", for instance in 211 [draft-ietf-pcn-cl-edge-behaviour-08], 212 [draft-ietf-pcn-sm-edge-behaviour-05]. 214 If so configured (e.g., because multipath routing is being used), the 215 PCN-egress-node MUST also include in the PCN feedback and report the 216 set of flow identifiers of PCN-flows for which excess-traffic-marking 217 was observed in the most recent measurement interval. 219 The representation of a flow ID depends on the surrounding 220 environment, e.g., "pure IP", MPLS, GMPLS, etc. Examples of such flow 221 ID representations can be found in [RFC2205], [RFC3175] [RFC3209], 222 [RFC3473]. 224 For more details see [draft-ietf-pcn-cl-edge-behaviour-08], [draft- 225 ietf-pcn-sm-edge-behaviour-04]. 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 carry the identity of the PCN-egress-node 248 that sends the message. 250 2.3.4 Carry Identification of ingress-egress-aggregates 252 The signaling protocol MUST carry the identity (address information) 253 of the ingress-egress-aggregates. 255 2.3.5 Signaling Load 257 The load generated by the signaling protocol SHOULD be minimized. 259 2.3.6 Reliability 261 There are situations that messages need to be received in a 262 reliable way. There are different ways of achieving reliability. The 263 specification of a mandatory solution of achieving this reliability 264 is out of the scope of this document. It can be however considered, 265 that when information is received on a regular fashion, additional 266 reliability measures Should Not be required. 268 2.3.7 Security 270 The PCN architecture [RFC5559] considers that all PCN-nodes are PCN- 271 enabled and trusted to operate correctly. In the context of this 272 document: 273 o PCN-signaling messages MUST NOT leak out of the PCN-domain. This 274 can be easily accomplished, since messages are sent to the PCN- 275 boundary-node's address; 276 o PCN-boundary-nodes MUST validate the signaling messages, to 277 avoid that they come from an attacker. Considering that all PCN- 278 nodes are trusted, see [RFC5559], this requirement could be 279 easily fulfilled by verifying whether a message arrives on an 280 interface internal to the PCN-domain. 282 2.4. Filter Specifications 284 In PCN the PCN-ingress-node and PCN-egress-nodes should be able to 285 identify the ingress-egress-aggregate to which each flow belongs. 286 Moreover, the PCN-egress-node also needs to associate an aggregate 287 with the address of the PCN-ingress-node for receiving reports, if 288 the PCN-ingress-node is the decision point. The filter specification 289 at the PCN-egress-nodes depends on the surrounding environment, e.g., 290 pure IP, MPLS, GMPLS. 291 In this document, a possible IP filter spec for pure IP is given as 292 an example. In this case the filter spec should be able to identify a 293 flow using (all or a subset of the) following information: 295 o source IP address; 297 o destination IP address; 299 o protocol identifier and higher layer (port) addressing; 301 o flow label (typical for IPv6); 303 o SPI field for IPsec encapsulated data; 305 o DSCP/TOS field; 307 o IP address of PCN-ingress-node; 309 o IP address of PCN-egress-node 311 3. Signaling Requirements between Decision Point and PCN-ingress-nodes 313 The decision point monitors and uses the PCN egress feedback sent by 314 the PCN-egress-node. There are situations that the decision point 315 must obtain an estimate of the rate at which PCN-traffic is being 316 admitted to the aggregate from the PCN-ingress-node. 317 In order to receive this information the decision point has to 318 request from the PCN-ingress-node to report the value of the PCN 319 traffic admitted to a certain ingress-egress-aggregate. 320 Note that if the decision point and the PCN-ingress-node are 321 collocated, then the information exchanges between the decision point 322 and PCN-ingress-node are internal operations. 324 3.1 Reporting Frequency 326 The PCN content sent by the PCN-ingress-node and Decision Point are 327 not sent regularly. 329 3.2 Reporting Information 331 3.2.1 PCN ingress Feedback 333 The PCN-ingress-node measures per ingress-egress-aggregate the 334 following rate 335 o rate of admitted PCN traffic 337 This value is reported in octets/second to the decision point as 338 soon as possible after receiving the request from the decision 339 point. This information is not sent regularly and SHOULD be 340 delivered reliably. 342 3.2.2 Decision Point Trigger 344 The decision point requests from the PCN-ingress-node to send for a 345 certain ingress-egress-aggregate, the value of the admitted PCN 346 traffic rate. This Decision Point Trigger message identifies the 347 ingress-egress-aggregate for which the admitted PCN traffic rate is 348 required. Moreover, since this Decision Point Trigger message sent by 349 the decision point to the PCN-ingress-node is not sent regularly, it 350 SHOULD be delivered reliably. 352 3.3 Signaling Requirements 354 This section describes the requirements for signaling protocols that 355 are used to carry the PCN ingress feedback and the Decision Point 356 Trigger. 358 3.3.1 Priority of Signaling Messages 360 Signaling messages SHOULD have a higher priority than data packets. 362 3.3.2 Local Information Exchange 364 Signaling messages MUST be able to carry: 365 o the PCN ingress feedback from the PCN-ingress-node to the 366 decision point; 367 o the Decision Point Trigger from the decision point to the PCN- 368 ingress-node. 370 3.3.3 Carry Identification of PCN edge Nodes and Decision Point 372 The signaling protocol MUST carry the identity: 373 o of the PCN-ingress-node that sends the message, 374 o of the decision point that sends the message. 376 3.3.4 Carry Identification of ingress-egress-aggregates 378 The signaling protocol MUST carry the identity (address information) 379 of the ingress-egress-aggregates. 381 3.3.5 Signaling Load 383 The load generated by the signaling protocol SHOULD be minimized. 385 3.3.6 Reliability 387 The PCN ingress feedback and the Decision Point Trigger are not sent 388 regularly and SHOULD be delivered reliably. There are different ways 389 of achieving reliability. The specification of a mandatory solution 390 of achieving this reliability is out of the scope of this document. 392 3.3.7 Security 394 The PCN architecture [RFC5559] considers that all PCN-nodes are PCN- 395 enabled and trusted to operate correctly. The decision point is a 396 PCN-node and therefore it is considered to be PCN-enabled and trusted 397 to operate correctly. In the context of this 398 document: 399 o PCN-signaling messages MUST NOT leak out of the PCN-domain. This 400 can be easily accomplished, since messages are sent to either the 401 PCN-boundary-node's address or the decision point's address, 402 o PCN-boundary-nodes MUST validate the signaling messages, to 403 avoid that they come from an attacker. Considering that all PCN- 404 nodes are trusted, see [RFC5559], this requirement could be 405 easily fulfilled by verifying whether a message either arrives on 406 an interface internal to the PCN-domain or that it is sent by a 407 decision point. 409 4. Security Considerations 411 [RFC5559] provides a general description of the security 412 considerations for PCN. This memo introduces the additional security 413 considerations described in Section 2.3.7 and Section 3.3.7. 415 5. IANA Considerations 417 This memo includes no request to IANA. 419 6. Acknowledgements 421 We would like to acknowledge the members of the PCN working group for 422 the discussions that generated the contents of this memo. 424 7. References 426 7.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, March 1997. 431 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 432 Architecture", RFC 5559, June 2009. 434 [draft-ietf-pcn-cl-edge-behaviour-08] T. Taylor, A, Charny, 435 F. Huang, G. Karagiannis, M. Menth, "PCN Boundary Node 436 Behaviour for the Controlled Load (CL) Mode of Operation 437 (Work in progress)", December 2010. 439 [draft-ietf-pcn-sm-edge-behaviour-05] A. Charny, J. Zhang, 440 G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node 441 Behaviour for the Single Marking (SM) Mode of Operation 442 (Work in progress)", December 2010. 444 7.2. Informative References 446 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 447 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 448 Functional Specification", RFC 2205, September 1997. 449 [RFC3175] Baker, F., Iturralde, C. Le Faucher, F., Davie, B., 450 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 451 RFC 3175, 2001. 453 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 454 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 455 Tunnels", RFC 3209, December 2001. 457 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 458 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 459 Engineering (RSVP-TE) Extensions", RFC 3473, 460 January 2003. 462 Authors' Addresses 464 Georgios Karagiannis 465 University of Twente 466 P.O. Box 217 467 7500 AE Enschede, 468 The Netherlands 469 EMail: g.karagiannis@ewi.utwente.nl 471 Tom Taylor 472 Huawei Technologies 473 1852 Lorraine Ave. 474 Ottawa, Ontario K1H 6Z8 475 Canada 476 Phone: +1 613 680 2675 477 Email: tom111.taylor@bell.net 479 Kwok Ho Chan 480 Huawei Technologies 481 125 Nagog Park 482 Acton, MA 01720 483 USA 484 Email: khchan@huawei.com 486 Michael Menth 487 University of Tuebingen 488 Department of Computer Science 489 Chair of Communication Networks 490 Sand 13 491 Tuebingen 72076 492 Germany 493 Phone: +49 7071 29 70505 494 Email: menth@informatik.uni-tuebingen.de