idnits 2.17.1 draft-taylor-pcn-piggybacking-edge-behaviour-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: ---------------------------------------------------------------------------- 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 == Line 297 has weird spacing: '...Control over...' -- The document date (March 8, 2010) is 5162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-CL-Edge-Behaviour - is the name correct? -- No information found for draft-SM-Edge-Behaviour - is the name correct? -- No information found for draft-NSLP - is the name correct? Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Taylor, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Informational March 8, 2010 5 Expires: September 9, 2010 7 The PCN Piggybacking Edge Behaviour 8 draft-taylor-pcn-piggybacking-edge-behaviour-01 10 Abstract 12 Precongestion notification (PCN) is a means for protecting quality of 13 service for inelastic traffic admitted to a Diffserv domain. The 14 overall PCN architecture is described in RFC 5559. This memo 15 describes a behaviour for PCN egress nodes known as the 16 "piggybacking" edge behaviour, because it "piggybacks" PCN 17 information in resource signalling messages. This version of the 18 memo describes two alternatives, where piggybacking is derived from 19 the CL edge behaviour and where it is derived from the SM edge 20 behaviour. The SM and CL edge behaviours are specified in companion 21 documents. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 9, 2010. 46 Copyright Notice 48 Copyright (c) 2010 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 BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Assumed Signalling Behaviour . . . . . . . . . . . . . . . . . 4 66 3. Assumed Behaviour at Interior Nodes . . . . . . . . . . . . . . 4 67 4. Edge Node Behaviours . . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Egress Node Behaviour . . . . . . . . . . . . . . . . . . . 4 69 4.1.1. Data Collection . . . . . . . . . . . . . . . . . . . . 4 70 4.1.2. Reporting . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.2. Ingress Node Behaviour . . . . . . . . . . . . . . . . . . 6 72 4.3. Decision Point Behaviour . . . . . . . . . . . . . . . . . 6 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 The main objective of Pre-Congestion Notification (PCN) is to support 84 the quality of service (QoS) of inelastic flows within a Diffserv 85 domain, in a simple, scalable, and robust fashion. Two mechanisms 86 are used: admission control and flow termination. Admission control 87 is used to decide whether to admit or block a new flow request, while 88 flow termination is used in abnormal circumstances to decide whether 89 to terminate some of the existing flows. To support these two 90 features the overall rate of PCN-traffic is metered on every link in 91 the domain, and PCN-packets are appropriately marked when certain 92 configured rates are exceeded. These configured rates are below the 93 rate of the link thus providing notification to boundary nodes about 94 overloads before any congestion occurs (hence "pre-congestion" 95 notification). The level of marking allows decisions to be made 96 about whether to admit or terminate individual flows. For more 97 details see [RFC5559]. 99 Boundary node behaviours specify a detailed set of algorithms and 100 edge node behaviours used to implement the PCN mechanisms. The 101 piggybacking edge behaviour which is the subject of this memo 102 introduces no new behaviours and algorithms beyond those provided by 103 the SM and CL edge behaviours ([I-D.SM-Edge-Behaviour] and 104 [I-D.CL-Edge-Behaviour] respectively). Instead, it provides an 105 alternative method of signalling whereby the egress node reports the 106 rates it has calculated as an addition to resource signalling rather 107 than using a separate protocol. This has implications both for the 108 operation of the resource signalling and the operation of the PCN 109 mechanisms. 111 1.1. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 In addition to the terms defined in [RFC5559], this document uses the 118 following terms: 120 decision point 121 The node that makes the decision about which flows to admit and to 122 terminate. In a given network deployment, this may be the ingress 123 node or a centralized control node. Decisions are enforced by the 124 ingress node. In contrast to the signalling architecture 125 considered in [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour], 126 in the piggybacking case the egress node always sends its 127 information to the ingress node rather than the decision point. 128 The ingress node then forwards the PCN reports to the decision 129 point if they are not collocated. The decision point returns its 130 decisions to the ingress node as usual. 132 NM-Rate, ThM-Rate, ETM-Rate 133 The calculated rate at which PCN traffic has been received in 134 unmarked packets, threshold-marked packets (CL mode only), and 135 excess-traffic-marked packets respectively. See the descriptions 136 of egress node behaviour in [I-D.SM-Edge-Behaviour] and 137 [I-D.CL-Edge-Behaviour] for further details. 139 2. Assumed Signalling Behaviour 141 For the piggybacking edge behaviour, it is assumed that applications 142 are using a resource signalling protocol (e.g., RSVP, NSIS) to 143 request resources from the network. The PCN domain is viewed as a 144 building block in the complete end-to-end path. Resource signalling 145 is processed by the edge nodes of the PCN domain, but not by the 146 interior nodes. Thus the passage from the PCN-ingress-node to the 147 PCN-egress-node or vice versa is viewed as a single hop. 149 It is assumed that a request for resources for a given flow requires 150 at least one message passing through the PCN-egress-node toward the 151 PCN-ingress-node. This is consistent with RSVP and some cases of 152 NSIS, but rules out "Basic Sender Initiated Reservation" as described 153 in Section 4.1 of [I-D.NSLP]. 155 3. Assumed Behaviour at Interior Nodes 157 It is assumed that nodes interior to the PCN domain do not 158 participate in the resource signalling, but simply forward that 159 signalling toward the edge. Beyond that, the applicable assumptions 160 are as described in [I-D.SM-Edge-Behaviour] and 161 [I-D.CL-Edge-Behaviour] respectively. 163 4. Edge Node Behaviours 165 4.1. Egress Node Behaviour 167 4.1.1. Data Collection 169 The PCN-egress-node MUST meter received PCN traffic per ingress- 170 egress-aggregate and periodically calculate the rate at which 171 unmarked, threshold-marked (for the CL behaviour), and excess- 172 traffic-marked traffic is received, all as described in 173 [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour] respectively. 175 The interval between successive calculations SHOULD be a constant 176 value of the order of 100 to 500 ms, as described in the CL and SM 177 documents. 179 If so configured, when operating in CL mode, the PCN-egress-node MUST 180 also save the identities of flows experiencing excess-traffic-marking 181 during the latest measurement interval. 183 4.1.2. Reporting 185 The PCN-egress-node reports its measured results according to the 186 following rules: 188 o When the PCN-egress-node receives resource signalling for a new 189 flow, it processes that message according to the rules of the 190 protocol. However, if the message is to be forwarded in the 191 direction of the PCN-ingress-node, the egress node MUST add to the 192 message an object containing its latest calculated values of NM- 193 rate, ThM-Rate (for CL mode only) and ETM-Rate for the ingress- 194 egress-aggregate which that flow would join. In addition, if 195 operating in CL mode and so configured, if the ETM-Rate is greater 196 than zero the PCN-egress-node SHOULD add to the message an object 197 identifying individual flows within the aggregate that experienced 198 excess-traffic marking. 200 There may not be space for this within the message. 202 o If the PCN-egress-node receives resource signalling refreshing 203 state for an established flow, it again processes the message 204 according to the rules of the protocol. OPEN ISSUE: Should it 205 attach the latest values of the calculated rates, or should it 206 attach the values that were placed into the original message 207 establishing that flow? The latter was suggested by 208 [I-D.lefaucheur-rsvp-ecn], to make it easier for implementations 209 to distinguish refresh messages. 211 o If the calculated ETM-Rate for an interval is greater than zero 212 and no resource signalling in the direction of the PCN-ingress- 213 node was received during that interval relating to the ingress- 214 egress-aggregate concerned, the PCN-egress-node SHOULD generate an 215 autonomous report identifying the ingress-egress-aggregate, giving 216 the calculated values of NM-Rate, ThM-Rate, and ETM-Rate, and, if 217 so configured, a list of individual flows that were excess- 218 traffic-marked in the interval just concluded. 220 The condition of no message in the right direction in the 221 previous interval is a heuristic for predicting whether one 222 will come along in the next interval. 224 OPEN ISSUE 1: can this use a message within the resource 225 protocol? RSVP messages are associated with individual flows. 226 Can an RSVP session between ingress and egress be set up 227 specifically for the aggregate, so that messages like this 228 relate to the aggregate as a whole? 230 OPEN ISSUE 2: does the message have to be delivered reliably? 232 4.2. Ingress Node Behaviour 234 When the PCN-ingress-node receives resource signalling from the 235 direction of the PCN-egress-node, it processes the message as 236 required by the resource protocol. Before forwarding it, it removes 237 any PCN-related information added by the egress node and forwards 238 that information to the decision point. 240 If the ingress node and the decision point are collocated, the 241 exchanges between them are an internal operation. 243 The PCN-ingress-node MUST provide the estimated current rate of 244 admitted PCN traffic (octets per second) for a specific ingress- 245 egress-aggregate when the decision point requests it, as described in 246 [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour]. 248 4.3. Decision Point Behaviour 250 Behaviour at the decision point is exactly as documented in 251 [I-D.SM-Edge-Behaviour] or [I-D.CL-Edge-Behaviour] as applicable. 253 5. Acknowledgements 255 draft-lefaucheur-rsvp-ecn-01.txt ([I-D.lefaucheur-rsvp-ecn]) covered 256 this ground in much greater detail, three and a half years ago. The 257 author borrowed some of the information from that document, but the 258 document itself should probably be revised to fit the present shape 259 of PCN if there is interest in this work. 261 6. IANA Considerations 263 This memo includes no request to IANA. 265 7. Security Considerations 267 To be written. 269 8. References 271 8.1. Normative References 273 [I-D.CL-Edge-Behaviour] 274 Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. 275 Taylor, Ed., "PCN Boundary Node Behaviour for the 276 Controlled Load (CL) Mode of Operation (Work in 277 progress)", 2010. 279 [I-D.SM-Edge-Behaviour] 280 Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. 281 Taylor, Ed., "PCN Boundary Node Behaviour for the Single 282 Marking (SM) Mode of Operation (Work in progress)", 2010. 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 8.2. Informative References 289 [I-D.NSLP] 290 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 291 Quality-of-Service Signaling (Work in progress)", 292 January 2010. 294 [I-D.lefaucheur-rsvp-ecn] 295 Le Faucheur, F., Charny, A., Briscoe, B., Eardley, P., 296 Chan, K., and J. Babiarz, "RSVP Extensions for Admission 297 Control over Diffserv using Pre-congestion Notification 298 (PCN) (Work in progress)", June 2006. 300 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 301 Architecture", RFC 5559, June 2009. 303 Author's Address 305 Tom Taylor (editor) 306 Huawei Technologies 307 1852 Lorraine Ave 308 Ottawa 309 Canada 311 Email: tom111.taylor@bell.net