idnits 2.17.1 draft-ietf-dime-qos-parameters-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 942. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 949. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 955. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 26, 2008) is 5811 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'S' is mentioned on line 371, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-tsvwg-emergency-rsvp-08 ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Informational RFC: RFC 3290 ** Downref: Normative reference to an Informational RFC: RFC 3564 == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-20 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen, Ed. 3 Extensions (DIME) TeliaSonera 4 Internet-Draft H. Tschofenig 5 Intended status: Standards Track Nokia Siemens Networks 6 Expires: November 27, 2008 May 26, 2008 8 Quality of Service Parameters for Usage with the AAA Framework 9 draft-ietf-dime-qos-parameters-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 27, 2008. 36 Abstract 38 This document defines a number of Quality of Service (QoS) parameters 39 that can be reused for conveying QoS information within RADIUS and 40 Diameter. 42 The payloads used to carry these QoS parameters are opaque for the 43 AAA client and the AAA server itself and interpreted by the 44 respective Resource Management Function. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 50 3. Parameter Overview . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Traffic Model Parameter . . . . . . . . . . . . . . . . . 3 52 3.2. Constraints Parameters . . . . . . . . . . . . . . . . . . 3 53 3.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5 54 3.4. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 5 55 4. Parameter Encoding . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Parameter Header . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . . 5 58 4.3. TMOD-2 Parameter . . . . . . . . . . . . . . . . . . . . . 6 59 4.4. Path Latency Parameter . . . . . . . . . . . . . . . . . . 7 60 4.5. Path Jitter Parameter . . . . . . . . . . . . . . . . . . 7 61 4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . . . . 8 62 4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . . . 8 63 4.8. Slack Term Parameter . . . . . . . . . . . . . . . . . . . 9 64 4.9. Preemption Priority amp; Defending Priority Parameters . . 9 65 4.10. Admission Priority Parameter . . . . . . . . . . . . . . . 10 66 4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10 67 4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 11 68 4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12 69 4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 13 70 4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 13 71 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 16 74 6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 16 75 6.3. Excess Treatment Parameter . . . . . . . . . . . . . . . . 17 76 6.4. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 17 77 6.5. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 18 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 84 Intellectual Property and Copyright Statements . . . . . . . . . . 22 86 1. Introduction 88 This document defines a number of Quality of Service (QoS) parameters 89 that can be reused for conveying QoS information within RADIUS and 90 Diameter. 92 The payloads used to carry these QoS parameters are opaque for the 93 AAA client and the AAA server itself and interpreted by the 94 respective Resource Management Function. 96 2. Terminology and Abbreviations 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC2119 [RFC2119]. 102 3. Parameter Overview 104 3.1. Traffic Model Parameter 106 The Traffic Model (TMOD) parameter is a container consisting of four 107 sub-parameters: 108 o rate (r) 109 o bucket size (b) 110 o peak rate (p) 111 o minimum policed unit (m) 113 All four sub-parameters MUST be included in the TMOD parameter. The 114 TMOD parameter is a mathematically complete way to describe the 115 traffic source. If, for example, TMOD is set to specify bandwidth 116 only, then set r = peak rate = p, b = large, m = large. As another 117 example if TMOD is set for TCP traffic, then set r = average rate, b 118 = large, p = large. 120 3.2. Constraints Parameters 122 , , , and are QoS 123 parameters describing the desired path latency, path jitter and path 124 bit error rate respectively. 126 The parameter refers to the accumulated latency of the 127 packet forwarding process associated with each QoS aware node along 128 the path, where the latency is defined to be the mean packet delay 129 added by each such node. This delay results from speed-of-light 130 propagation delay, from packet processing limitations, or both. The 131 mean delay reflects the variable queuing delay that may be present. 133 The purpose of this parameter is to provide a minimum path latency 134 for use with services which provide estimates or bounds on additional 135 path delay [RFC2212]. 137 The procedures for collecting path latency information are outside 138 the scope of this document. 140 The parameter refers to the accumulated jitter of the 141 packet forwarding process associated with each QoS aware node along 142 the path, where the jitter is defined to be the nominal jitter added 143 by each such node. IP packet jitter, or delay variation, is defined 144 in Section 3.4 of RFC 3393 [RFC3393], (Type-P-One-way-ipdv), and 145 where the selection function includes the packet with minimum delay 146 such that the distribution is equivalent to 2-point delay variation 147 in [Y.1540]. The suggested evaluation interval is 1 minute. This 148 jitter results from packet processing limitations, and includes any 149 variable queuing delay which may be present. The purpose of this 150 parameter is to provide a nominal path jitter for use with services 151 that provide estimates or bounds on additional path delay [RFC2212]. 153 The procedures for collecting path jitter information are outside the 154 scope of this document. 156 The parameter refers to the accumulated packet loss rate 157 (PLR) of the packet forwarding process associated with each QoS aware 158 node along the path where the PLR is defined to be the PLR added by 159 each such node. 161 The parameter refers to the accumulated packet error rate 162 (PER) of the packet forwarding process associated with each QoS aware 163 node, where the PER is defined to be the PER added by each such node. 165 The parameter refers to the difference between desired 166 delay and delay obtained by using bandwidth reservation, and which is 167 used to reduce the resource reservation for a flow [RFC2212]. 169 The parameter refers to the priority of the new 170 flow compared with the of previously admitted 171 flows. Once a flow is admitted, the preemption priority becomes 172 irrelevant. The parameter is used to compare 173 with the preemption priority of new flows. For any specific flow, 174 its preemption priority MUST always be less than or equal to the 175 defending priority. and provide 176 an essential way to differentiate flows for emergency services, ETS, 177 E911, etc., and assign them a higher admission priority than normal 178 priority flows and best-effort priority flows. 180 3.3. Traffic Handling Directives 182 The parameter describes how a QoS aware node will 183 process excess traffic, that is, out-of-profile traffic. Excess 184 traffic MAY be dropped, shaped and/or remarked. 186 3.4. Traffic Classifiers 188 Resource reservations might refer to a packet processing with a 189 particular DiffServ per-hop behavior (PHB) [RFC2475] or to a 190 particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS 191 traffic engineering (DSTE) class type [RFC3564], [RFC4124]. 193 4. Parameter Encoding 195 4.1. Parameter Header 197 Each QoS parameter is encoded in TLV format. 199 0 1 2 3 200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 |M|r|r|r| Parameter ID |r|r|r|r| Length | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 M Flag: When set indicates the subsequent parameter MUST be 206 interpreted. If the M flag is set and the parameter is not 207 understood then it leads to an error. If the M flag is not 208 set and then not understood then it can be ignored. 210 The r bits are reserved. 212 Parameter ID: Assigned to each individual QoS parameter 214 4.2. TMOD-1 Parameter 216 =

[RFC2210] , [RFC2215] 218 The above notation means that the 4 sub-parameters must be 219 carried in the parameter. The coding for the 220 parameter is as follows: 222 0 1 2 3 223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |M|r|r|r| 1 |r|r|r|r| 4 | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | TMOD Rate-1 [r] (32-bit IEEE floating point number) | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | TMOD Size-1 [b] (32-bit IEEE floating point number) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 The parameters are represented by three floating point numbers 237 in single-precision IEEE floating point format followed by one 32-bit 238 integer in network byte order. The first floating point value is the 239 rate (r), the second floating point value is the bucket size (b), the 240 third floating point is the peak rate (p), and the first unsigned 241 integer is the minimum policed unit (m). 243 When r, b, and p terms are represented as IEEE floating point values, 244 the sign bit MUST be zero (all values MUST be non-negative). 245 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 246 than 162 (i.e., positive 35) are discouraged, except for specifying a 247 peak rate of infinity. Infinity is represented with an exponent of 248 all ones (255) and a sign bit and mantissa of all zeroes. 250 4.3. TMOD-2 Parameter 252 A description of the semantic of the parameter values can be found in 253 [RFC2215]. The parameter may be needed in a DiffServ 254 environment. The coding for the parameter is as follows: 256 0 1 2 3 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |M|r|r|r| 2 |r|r|r|r| 4 | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | TMOD Rate-2 [r] (32-bit IEEE floating point number) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | TMOD Size-2 [b] (32-bit IEEE floating point number) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Peak Data Rate-2 [p] (32-bit IEEE floating point number) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Minimum Policed Unit-2 [m] (32-bit unsigned integer) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 When r, b, and p terms are represented as IEEE floating point values, 271 the sign bit MUST be zero (all values MUST be non-negative). 273 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater 274 than 162 (i.e., positive 35) are discouraged, except for specifying a 275 peak rate of infinity. Infinity is represented with an exponent of 276 all ones (255) and a sign bit and mantissa of all zeroes. 278 4.4. Path Latency Parameter 280 A description of the semantic of the parameter values can be found in 281 [RFC2210],[RFC2215]. The coding for the parameter is 282 as follows: 284 0 1 2 3 285 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |M|r|r|r| 3 |r|r|r|r| 1 | 288 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 289 | Path Latency (32-bit integer) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 The Path Latency is a single 32-bit integer in network byte order. 293 The composition rule for the parameter is summation 294 with a clamp of (2**32 - 1) on the maximum value. The latencies are 295 average values reported in units of one microsecond. A system with 296 resolution less than one microsecond MUST set unused digits to zero. 297 The total latency added across all QoS aware nodes along the path can 298 range as high as (2**32)-2. 300 4.5. Path Jitter Parameter 302 The coding for the parameter is as follows: 304 0 1 2 3 305 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 |M|r|r|r| 4 |r|r|r|r| 4 | 308 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 309 | Path Jitter STAT1(variance) (32-bit integer) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Path Jitter STAT2(99.9%-ile) (32-bit integer) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Path Jitter STAT3(minimum Latency) (32-bit integer) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Path Jitter STAT4(Reserved) (32-bit integer) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 The Path Jitter is a set of four 32-bit integers in network byte 319 order. The Path Jitter parameter is the combination of four 320 statistics describing the Jitter distribution with a clamp of (2**32 321 - 1) on the maximum of each value. The jitter STATs are reported in 322 units of one microsecond. 324 4.6. Path PLR Parameter 326 The coding for the parameter is as follows: 328 0 1 2 3 329 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |M|r|r|r| 5 |r|r|r|r| 1 | 332 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 333 | Path Packet Loss Ratio (32-bit floating point) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 The Path PLR is a single 32-bit single precision IEEE floating point 337 number in network byte order. The PLRs are reported in units of 338 10^-11. A system with resolution less than one microsecond MUST set 339 unused digits to zero. The total PLR added across all QoS aware 340 nodes can range as high as 10^-1. 342 4.7. Path PER Parameter 344 The coding for the parameter is as follows: 346 0 1 2 3 347 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |M|r|r|r| 6 |r|r|r|r| 1 | 350 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 351 | Path Packet Error Ratio (32-bit floating point) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 The Path PER is a single 32-bit single precision IEEE floating point 355 number in network byte order. The PERs are reported in units of 356 10^-11. A system with resolution less than one microsecond MUST set 357 unused digits to zero. The total PER added across all QoS aware 358 nodes can range as high as 10^-1. 360 4.8. Slack Term Parameter 362 A description of the semantic of the parameter values can be found in 363 [RFC2212], [RFC2215]. The coding for the parameter is as 364 follows: 366 0 1 2 3 367 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |M|r|r|r| 7 |r|r|r|r| 1 | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Slack Term [S] (32-bit integer) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 The Slack Term parameter S is a 32-bit integer value in network byte 375 order and is measured in microseconds. S is represented as a 32-bit 376 integer. Its value can range from 0 to (2**32)-1 microseconds. 378 4.9. Preemption Priority amp; Defending Priority Parameters 380 A description of the semantic of the parameter values can be found in 381 [RFC3181]. 383 The coding for the & sub- 384 parameters is as follows: 386 0 1 2 3 387 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |M|r|r|r| 8 |r|r|r|r| 1 | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Preemption Priority | Defending Priority | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Preemption Priority: The priority of the new flow compared with the 395 defending priority of previously admitted flows. Higher values 396 represent higher priority. 398 Defending Priority: Once a flow is admitted, the preemption priority 399 becomes irrelevant. Instead, its defending priority is used to 400 compare with the preemption priority of new flows. 402 As specified in [RFC3181], & are 16-bit integer values. They are represented in network 404 byte order. 406 4.10. Admission Priority Parameter 408 The coding for the parameter is as follows: 410 0 1 2 3 411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |M|r|r|r| 9 |r|r|r|r| 1 | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Admis.Priority| (Reserved) | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 The 'Admis.Priority' field is a 8 bit unsigned integer in network 419 byte order. 421 The admission control priority of the flow, in terms of access to 422 network bandwidth in order to provide higher probability of call 423 completion to selected flows. Higher values represent higher 424 priority. A given Admission Priority is encoded in this information 425 element using the same value as when encoded in the Admission 426 Priority parameter defined in Section 6.2.9 of [I-D.ietf-nsis-qspec], 427 or in the Admission Priority parameter defined in Section 3.1 of 428 [I-D.ietf-tsvwg-emergency-rsvp]. In other words, a given value 429 inside the Admission Priority information element defined in the 430 present document, inside the [I-D.ietf-nsis-qspec] Admission Priority 431 parameter or inside the [I-D.ietf-tsvwg-emergency-rsvp] Admission 432 Priority parameter, refers to the same Admission Priority. 434 4.11. Application-Level Resource Priority (ALRP) Parameter 436 A description of the semantic of the parameter values can be found in 437 [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for 438 parameter is as follows: 440 0 1 2 3 441 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 |M|r|r|r| 10 |r|r|r|r| 1 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | ALRP Namespace | ALRP Priority | (Reserved) | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 The ALRP Namespace field is a 16 bits long unsigned integer in 449 network byte order and the ALRP Priority field is an 8 bit long 450 unsigned integer in network byte order containing the specific 451 priority value. 453 [RFC4412] defines a resource priority header and established the 454 initial registry; that registry was later extended by 455 [I-D.ietf-tsvwg-emergency-rsvp]. 457 4.12. Excess Treatment Parameter 459 The coding for the parameter is as follows: 461 0 1 2 3 462 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |M|r|r|r| 11 |r|r|r|r| 1 | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Excess Trtmnt | Remark Value | Reserved | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Excess Treatment (8 bit unsigned integer value in network byte 470 order): Indicates how the QoS aware node should process out-of- 471 profile traffic, that is, traffic not covered by the 472 parameter. Allowed values are as follows: 474 0: drop 475 1: shape 476 2: remark 477 3: no metering or policing is permitted 479 The default excess treatment in case that none is specified is that 480 there are no guarantees to excess traffic, i.e., a QoS aware node can 481 do what it finds suitable. 483 When excess treatment is set to 'drop', all marked traffic MUST be 484 dropped by a QoS aware node. 486 When excess treatment is set to 'shape', it is expected that the QoS 487 Desired object carries a TMOD parameter. Excess traffic is to be 488 shaped to this TMOD. When the shaping causes unbounded queue growth 489 at the shaper traffic can be dropped. 491 When excess treatment is set to 'remark', the excess treatment 492 parameter MUST carry the remark value. For example, packets may be 493 remarked to drop remarked to pertain to a particular QoS class. In 494 the latter case, remarking relates to a DiffServ-type model, where 495 packets arrive marked as belonging to a certain QoS class, and when 496 they are identified as excess, they should then be remarked to a 497 different QoS Class. 499 If 'no metering or policing is permitted' is signaled, the QoS aware 500 node should accept the excess treatment parameter set by the sender 501 with special care so that excess traffic should not cause a problem. 502 To request the Null Meter [RFC3290] is especially strong, and should 503 be used with caution. 505 The Remark Value is an 8 bit unsigned integer value in network byte 506 order. 508 4.13. PHB Class Parameter 510 A description of the semantic of the parameter values can be found in 511 [RFC3140]. The coding for the parameter is as follows: 513 0 1 2 3 514 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 |M|r|r|r| 12 |r|r|r|r| 1 | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | 519 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 521 As prescribed in [RFC3140], the encoding for a single PHB is the 522 recommended DSCP value for that PHB, left-justified in the 16 bit 523 field, with bits 6 through 15 set to zero. 525 The encoding for a set of PHBs is the numerically smallest of the set 526 of encodings for the various PHBs in the set, with bit 14 set to 1. 527 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 528 bit 14 set to 1.) 530 0 1 531 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | DSCP |0 0 0 0 0 0 0 0 X 0| 534 +---+---+---+---+---+---+---+---+ 536 PHBs not defined by standards action, i.e., experimental or local use 537 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 538 identification code, assigned by the IANA, is placed left-justified 539 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 540 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 542 0 1 543 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | PHD ID CODE |0 0 X 0| 546 +---+---+---+---+---+---+---+---+ 548 Bits 12 and 13 are reserved either for expansion of the PHB 549 identification code, or for other use, at some point in the future. 551 In both cases, when a single PHBID is used to identify a set of PHBs 552 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 553 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 554 intra-microflow traffic reordering when different PHBs from the set 555 are applied to traffic in the same microflow). The set of AF1x PHBs 556 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that 557 do not constitute a PHB Scheduling Class can be identified by using 558 more than one PHBID. 560 The registries needed to use [RFC3140] already exist. Hence, no new 561 registry needs to be created for this purpose. 563 4.14. DSTE Class Type Parameter 565 A description of the semantic of the parameter values can be found in 566 [RFC4124]. The coding for the parameter is as 567 follows: 569 0 1 2 3 570 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 |M|r|r|r| 13 |r|r|r|r| 1 | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 |DSTE Cls. Type | (Reserved) | 575 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 577 DSTE Class Type: Indicates the DSTE class type. Values currently 578 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 579 that the parameter is not used. 581 4.15. Y.1541 QoS Class Parameter 583 A description of the semantic of the parameter values can be found in 584 [Y.1541]. The coding for the parameter is as 585 follows: 587 0 1 2 3 588 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |M|r|r|r| 14 |r|r|r|r| 1 | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 |Y.1541 QoS Cls.| (Reserved) | 593 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 595 Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently 596 allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 597 that the parameter is not used. 599 Class 0: 601 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 602 10^-3. Real-time, highly interactive applications, sensitive to 603 jitter. Application examples include VoIP, Video Teleconference. 605 Class 1: 607 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 608 10^-3. Real-time, interactive applications, sensitive to jitter. 609 Application examples include VoIP, Video Teleconference. 611 Class 2: 613 Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 614 10^-3. Highly interactive transaction data. Application examples 615 include signaling. 617 Class 3: 619 Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 620 10^-3. Interactive transaction data. Application examples 621 include signaling. 623 Class 4: 625 Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 626 10^-3. Low Loss Only applications. Application examples include 627 short transactions, bulk data, video streaming. 629 Class 5: 631 Mean delay unspecified, delay variation unspecified, loss ratio 632 unspecified. Unspecified applications. Application examples 633 include traditional applications of default IP networks. 635 Class 6: 637 Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 638 10^-5. Applications that are highly sensitive to loss, such as 639 television transport, high-capacity TCP transfers, and TDM circuit 640 emulation. 642 Class 7: 644 Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 645 10^-5. Applications that are highly sensitive to loss, such as 646 television transport, high-capacity TCP transfers, and TDM circuit 647 emulation. 649 5. Extensibility 651 This document is designed with extensibility in mind given that 652 different organizations and groups are used to define their own 653 Quality of Service parameters. This document provides an initial QoS 654 profile with common set of parameters. Ideally, these parameters 655 should be used whenever possible but there are cases where additional 656 parameters might be needed, or where the parameters specified in this 657 document are used with a different semantic. In this case it is 658 advisable to define a new QoS profile that may consist of new 659 parameters in addition to parameters defined in this document or an 660 entirely different set of parameters. 662 To enable the definition of new QoS profiles a 8 octet registry is 663 defined field that is represented by a 4-octet vendor and 4-octet 664 specifier field. The vendor field indicates the type as either 665 standards-specified or vendor-specific. If the four octets of the 666 vendor field are 0x00000000, then the value is standards-specified 667 and the registry is maintained by IANA, and any other value 668 represents a vendor-specific Object Identifier (OID). IANA created 669 registry is split into two value ranges; one range uses the 670 "Standards Action" and the second range uses "Specification Required" 671 allocation policy. The latter range is meant to be used by 672 organizations outside the IETF. 674 6. IANA Considerations 676 This section defines the registries and initial codepoint 677 assignments, in accordance with BCP 26 RFC 2434 [RFC2434]. It also 678 defines the procedural requirements to be followed by IANA in 679 allocating new codepoints. 681 IANA is requested to create the following registries listed in the 682 subsections below. 684 6.1. QoS Profile 686 The QoS Profile refers to a 64 bit long field that is represented by 687 a 4-octet vendor and 4-octet specifier field. The vendor field 688 indicates the type as either standards-specified or vendor-specific. 689 If the four octets of the vendor field are 0x00000000, then the value 690 is standards-specified and the registry is maintained by IANA, and 691 any other value represents a vendor-specific Object Identifier (OID). 693 The specifier field indicates the actual QoS profile. The vendor 694 field 0x00000000 is reserved to indicate that the values in the 695 specifier field are maintained by IANA. This document requests IANA 696 to create such a registry and to allocate the value zero (0) for the 697 QoS profile defined in this document. 699 For any other vendor field, the specifier field is maintained by the 700 vendor. 702 For the IANA maintained QoS profiles the following allocation policy 703 is defined: 704 1 to 511: Standards Action 705 512 to 4095: Specification Required 707 Standards action is required to depreciate, delete, or modify 708 existing QoS profile values in the range of 0-511 and a specification 709 is required to depreciate, delete, or modify existing QoS profile 710 values in the range of 512-4095. 712 6.2. Parameter ID 714 The Parameter ID refers to a 12 bit long field. 716 The following values are allocated by this specification. 718 (0): 719 (1): 720 (2): 721 (3): 722 (4): 723 (5): 724 (6): 725 (7): & 726 (8): 727 (9): 728 (10): 729 (11): 730 (12): 731 (13): 733 The allocation policies for further values are as follows: 734 14-127: Standards Action 735 128-255: Private/Experimental Use 736 255-4095: Specification Required 738 A standards track document is required to depreciate, delete, or 739 modify existing Parameter IDs. 741 6.3. Excess Treatment Parameter 743 The Excess Treatment parameter refers to an 8 bit long field. 745 The following values are allocated by this specification: 746 Excess Treatment Value 0: drop 747 Excess Treatment Value 1: shape 748 Excess Treatment Value 2: remark 749 Excess Treatment Value3: no metering or policing is permitted 750 Excess Treatment Values 4-63: Standards Action 751 Excess Treatment Value 64-255: Reserved 753 The 8 bit Remark Value allocation policies are as follows: 754 0-63: Specification Required 755 64-127: Private/Experimental Use 756 128-255: Reserved 758 6.4. DSTE Class Type Parameter 760 The DSTE Class Type parameter refers to an 8 bit long field. 762 The following values are allocated by this specification: 763 DSTE Class Type Value 0: DSTE Class Type 0 764 DSTE Class Type Value 1: DSTE Class Type 1 765 DSTE Class Type Value 2: DSTE Class Type 2 766 DSTE Class Type Value 3: DSTE Class Type 3 767 DSTE Class Type Value 4: DSTE Class Type 4 768 DSTE Class Type Value 5: DSTE Class Type 5 769 DSTE Class Type Value 6: DSTE Class Type 6 770 DSTE Class Type Value 7: DSTE Class Type 7 771 DSTE Class Type Values 8-63: Standards Action 772 DSTE Class Type Values 64-255: Reserved 774 6.5. Y.1541 QoS Class Parameter 776 The Y.1541 QoS Class parameter refers to an 8 bit long field. 778 The following values are allocated by this specification: 779 Y.1541 QoS Class Value 0: Y.1541 QoS Class 0 780 Y.1541 QoS Class Value 1: Y.1541 QoS Class 1 781 Y.1541 QoS Class Value 2: Y.1541 QoS Class 2 782 Y.1541 QoS Class Value 3: Y.1541 QoS Class 3 783 Y.1541 QoS Class Value 4: Y.1541 QoS Class 4 784 Y.1541 QoS Class Value 5: Y.1541 QoS Class 5 785 Y.1541 QoS Class Value 6: Y.1541 QoS Class 6 786 Y.1541 QoS Class Value 7: Y.1541 QoS Class 7 787 Y.1541 QoS Class Values 8-63: Standards Action 788 Y.1541 QoS Class Values 64-255: Reserved 790 The ALRP Namespace and ALRP Priority field inside the ALRP Parameter 791 take their values from the registry created by [RFC4412] and extended 792 with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are 793 required by IANA by this specification. 795 7. Security Considerations 797 This document does not raise any security concerns as it only defines 798 QoS parameters. 800 8. Acknowledgements 802 The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] 803 authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the 804 NSIS working group chairs (John Loughney and Martin Stiemerling) and 805 the former Transport Area Directors (Allison Mankin, Jon Peterson) 806 for their help. 808 We would like to thank Francois Le Faucheur, John Loughney, Martin 809 Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars 810 Eggert, and Magnus Westerlund for their help with resolving problems 811 regarding the Admission Priority and the ALRP parameter. 813 9. References 815 9.1. Normative References 817 [I-D.ietf-tsvwg-emergency-rsvp] 818 Faucheur, F., Polk, J., and K. Carlberg, "Resource 819 ReSerVation Protovol (RSVP) Extensions for Emergency 820 Services", draft-ietf-tsvwg-emergency-rsvp-08 (work in 821 progress), May 2008. 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, March 1997. 826 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 827 Services", RFC 2210, September 1997. 829 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 830 of Guaranteed Quality of Service", RFC 2212, 831 September 1997. 833 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 834 Parameters for Integrated Service Network Elements", 835 RFC 2215, September 1997. 837 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 838 "Definition of the Differentiated Services Field (DS 839 Field) in the IPv4 and IPv6 Headers", RFC 2474, 840 December 1998. 842 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 843 and W. Weiss, "An Architecture for Differentiated 844 Services", RFC 2475, December 1998. 846 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 847 "Assured Forwarding PHB Group", RFC 2597, June 1999. 849 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 850 "Per Hop Behavior Identification Codes", RFC 3140, 851 June 2001. 853 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 854 RFC 3181, October 2001. 856 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 857 Informal Management Model for Diffserv Routers", RFC 3290, 858 May 2002. 860 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 861 Metric for IP Performance Metrics (IPPM)", RFC 3393, 862 November 2002. 864 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 865 Differentiated Services-aware MPLS Traffic Engineering", 866 RFC 3564, July 2003. 868 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 869 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 870 June 2005. 872 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 873 Priority for the Session Initiation Protocol (SIP)", 874 RFC 4412, February 2006. 876 [Y.1541] "Network Performance Objectives for IP-Based Services", , 877 2006. 879 [Y.1571] "Admission Control Priority Levels in Next Generation 880 Networks", , July 2006. 882 9.2. Informative References 884 [I-D.ietf-nsis-qspec] 885 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 886 QSPEC Template", draft-ietf-nsis-qspec-20 (work in 887 progress), April 2008. 889 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 890 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 891 October 1998. 893 [Y.1540] "Internet Protocol Data Communication Service - IP Packet 894 Transfer and Availability Performance Parameters", , 895 December 2002. 897 Authors' Addresses 899 Jouni Korhonen (editor) 900 TeliaSonera 901 Teollisuuskatu 13 902 Sonera FIN-00051 903 Finland 905 Email: jouni.korhonen@teliasonera.com 907 Hannes Tschofenig 908 Nokia Siemens Networks 909 Linnoitustie 6 910 Espoo 02600 911 Finland 913 Phone: +358 (50) 4871445 914 Email: Hannes.Tschofenig@nsn.com 915 URI: http://www.tschofenig.priv.at 917 Full Copyright Statement 919 Copyright (C) The IETF Trust (2008). 921 This document is subject to the rights, licenses and restrictions 922 contained in BCP 78, and except as set forth therein, the authors 923 retain all their rights. 925 This document and the information contained herein are provided on an 926 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 927 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 928 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 929 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 930 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 931 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 933 Intellectual Property 935 The IETF takes no position regarding the validity or scope of any 936 Intellectual Property Rights or other rights that might be claimed to 937 pertain to the implementation or use of the technology described in 938 this document or the extent to which any license under such rights 939 might or might not be available; nor does it represent that it has 940 made any independent effort to identify any such rights. Information 941 on the procedures with respect to rights in RFC documents can be 942 found in BCP 78 and BCP 79. 944 Copies of IPR disclosures made to the IETF Secretariat and any 945 assurances of licenses to be made available, or the result of an 946 attempt made to obtain a general license or permission for the use of 947 such proprietary rights by implementers or users of this 948 specification can be obtained from the IETF on-line IPR repository at 949 http://www.ietf.org/ipr. 951 The IETF invites any interested party to bring to its attention any 952 copyrights, patents or patent applications, or other proprietary 953 rights that may cover technology that may be required to implement 954 this standard. Please address the information to the IETF at 955 ietf-ipr@ietf.org.