idnits 2.17.1 draft-ietf-dime-qos-attributes-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- == There are 43 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5402 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1D' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1Q' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1ad' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.2' ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-09 -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen 3 Extensions (DIME) H. Tschofenig 4 Internet-Draft Nokia Siemens Networks 5 Intended status: Standards Track M. Arumaithurai 6 Expires: January 14, 2010 University of Goettingen 7 M. Jones, Ed. 8 A. Lior 9 Bridgewater Systems 10 July 13, 2009 12 Quality of Service Attributes for Diameter 13 draft-ietf-dime-qos-attributes-13.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on January 14, 2010. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This document extends the IPFilterRule AVP functionality of the 61 Diameter Base protocol and the functionality of the QoS-Filter-Rule 62 AVP defined in RFC 4005. The ability to convey Quality of Service 63 information using the AVPs defined in this document is available to 64 existing and future Diameter applications where permitted by the 65 command ABNF. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Rule Sets and Rules . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 5 73 3.2. QoS-Rule AVP . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.3. QoS-Rule-Precedence AVP . . . . . . . . . . . . . . . . . 7 75 4. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 7 77 4.1.1. Classifier AVP . . . . . . . . . . . . . . . . . . . . 9 78 4.1.2. Classifier-ID AVP . . . . . . . . . . . . . . . . . . 10 79 4.1.3. Protocol AVP . . . . . . . . . . . . . . . . . . . . . 10 80 4.1.4. Direction AVP . . . . . . . . . . . . . . . . . . . . 10 81 4.1.5. From-Spec AVP . . . . . . . . . . . . . . . . . . . . 10 82 4.1.6. To-Spec AVP . . . . . . . . . . . . . . . . . . . . . 11 83 4.1.7. Source and Destination AVPs . . . . . . . . . . . . . 12 84 4.1.8. Header Option AVPs . . . . . . . . . . . . . . . . . . 16 85 4.2. Time Of Day AVPs . . . . . . . . . . . . . . . . . . . . . 23 86 4.2.1. Time-Of-Day-Condition AVP . . . . . . . . . . . . . . 23 87 4.2.2. Time-Of-Day-Start AVP . . . . . . . . . . . . . . . . 23 88 4.2.3. Time-Of-Day-End AVP . . . . . . . . . . . . . . . . . 24 89 4.2.4. Day-Of-Week-Mask AVP . . . . . . . . . . . . . . . . . 24 90 4.2.5. Day-Of-Month-Mask AVP . . . . . . . . . . . . . . . . 24 91 4.2.6. Month-Of-Year-Mask AVP . . . . . . . . . . . . . . . . 24 92 4.2.7. Absolute-Start-Time AVP . . . . . . . . . . . . . . . 25 93 4.2.8. Absolute-Start-Fractional-Seconds AVP . . . . . . . . 25 94 4.2.9. Absolute-End-Time AVP . . . . . . . . . . . . . . . . 25 95 4.2.10. Absolute-End-Fractional-Seconds AVP . . . . . . . . . 25 96 4.2.11. Timezone-Flag AVP . . . . . . . . . . . . . . . . . . 26 97 4.2.12. Timezone-Offset AVP . . . . . . . . . . . . . . . . . 26 98 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 5.1. QoS-Action AVP . . . . . . . . . . . . . . . . . . . . . . 26 100 5.2. QoS-Profile-Id AVP . . . . . . . . . . . . . . . . . . . . 27 101 5.3. QoS-Profile-Template AVP . . . . . . . . . . . . . . . . . 27 102 5.4. QoS-Semantics . . . . . . . . . . . . . . . . . . . . . . 28 103 5.5. QoS-Parameters AVP . . . . . . . . . . . . . . . . . . . . 29 104 5.6. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 29 105 6. QoS Capability Indication . . . . . . . . . . . . . . . . . . 30 106 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 107 7.1. Diameter EAP with QoS Information . . . . . . . . . . . . 30 108 7.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 31 109 7.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 32 110 7.4. Diameter Server Initiated Re-authorization of QoS . . . . 33 111 7.5. Diameter Credit Control with QoS Information . . . . . . . 34 112 7.6. Classifier Examples . . . . . . . . . . . . . . . . . . . 35 113 7.7. QoS Examples . . . . . . . . . . . . . . . . . . . . . . . 36 114 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 115 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37 116 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 117 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 118 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 119 12.1. Normative References . . . . . . . . . . . . . . . . . . . 40 120 12.2. Informative References . . . . . . . . . . . . . . . . . . 41 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 123 1. Introduction 125 This document defines a number of Diameter Quality of Service (QoS) 126 related AVPs that can be used in existing and future Diameter 127 applications where permitted by the ABNF of a command. The 128 IPFilterRule AVP, defined in RFC 3588 [RFC3588], and the QoS-Filter- 129 Rule AVP, defined in RFC 4005 [RFC4005], provide basic support for 130 classification and QoS already. The classification rule syntax is a 131 modified subset of FreeBSD ipfw packet filter implementation. The 132 QoS functionality provided by the IPFilterRule AVP was updated by the 133 QoS-Filter-Rule AVP. The QoS-Rule AVP offers an extended way of 134 expressing classification and QoS capabilities. 136 The QoS-Resources AVP represents a complete rule set with each rule 137 represented by a QoS-Rule AVP. Each rule consists of a conditions 138 part and the corresponding actions to be performed if the conditions 139 are satisfied. The AVPs responsible for expressing a condition are 140 defined in Section 4. The capability to match all or a subset of the 141 data traffic is provided and this includes the ability to match on 142 Ethernet specific attributes which was not possible with the QoS- 143 Filter-Rule AVP. Additionally, time-based conditions can be 144 expressed based on the functionality offered in Section 4.2. The 145 action part of a rule contains information for handling conflict 146 resolution, such as a priority value for each individual rule within 147 a rule set, and further description regarding QoS related actions. 149 The QoS policy rules are defined as Diameter encoded Attribute Value 150 Pairs (AVPs) described using a modified version of the Augmented 151 Backus-Naur Form (ABNF), see [RFC3588]. The AVP datatypes are also 152 taken from [RFC3588]. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 3. Rule Sets and Rules 162 As mentioned in the introduction the top-level element is the QoS- 163 Resources AVP that encapsulates one or more QoS-Rule AVPs. 165 3.1. QoS-Resources AVP 167 The QoS-Resources AVP (AVP Code TBD) is of type Grouped and contains 168 a list of QoS policy rules. 170 QoS-Resources ::= < AVP Header: XXX > 171 1*{ QoS-Rule } 172 * [ AVP ] 174 3.2. QoS-Rule AVP 176 The QoS-Rule AVP (AVP Code TBD) is of type Grouped and defines a 177 specific condition and action combination. 179 QoS-Rule ::= < AVP Header: XXX > 180 [ QoS-Rule-Precedence ] 182 ; Condition part of a Rule 183 ; ------------------------ 185 [ Classifier ] 186 * [ Time-Of-Day-Condition ] 188 ; Action and Meta-Data 189 ; -------------------- 191 [ QoS-Action ] 193 ; Info about QoS related Actions 194 ; ------------------------------ 196 [ QoS-Semantics ] 197 [ QoS-Profile-Template ] 198 [ QoS-Parameters ] 199 [ Excess-Treatment ] 201 ; Extension Point 202 ; --------------- 203 * [ AVP ] 205 If the QoS-Profile-Template AVP is not included in the Qos-Rule AVP 206 then the default setting is assumed, namely a setting of the 207 Vendor-Id AVP to 0 (for IETF) and the QoS-Profile-Id AVP to zero (0) 208 (for the profile defined in [I-D.ietf-dime-qos-parameters]). Note 209 that the content of the QoS-Parameters are defined in the respective 210 specification defining the QoS parameters. When the Vendor-Id AVP is 211 set to 0 (for IETF) and the QoS-Profile-Id AVP is set to zero (0) 212 then the AVPs included in the QoS-Parameters AVP are the AVPs defined 213 in [I-D.ietf-dime-qos-parameters]. 215 3.3. QoS-Rule-Precedence AVP 217 The QoS-Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and 218 specifies the execution order of the rules expressed in the QoS- 219 Resources AVP. The lower the numerical value of QoS-Rule-Precedence 220 AVP, the higher the rule precedence. Rules with equal precedence MAY 221 be executed in parallel if supported by the Resource Management 222 Function. If the QoS-Rule-Precedence AVP is absent from the QoS-Rule 223 AVP, the rules SHOULD be executed in the order in which they appear 224 in the QoS-Resources AVP. 226 4. Conditions 228 This section describes the condition part of a rule. Two condition 229 types are introduced by this document: packet classification 230 conditions represented by the Classifier AVP and time of day 231 conditions represented by the Time-Of-Day-Condition AVP. 233 If more than one instance of the Time-Of-Day-Condition AVP is present 234 in the QoS-Rule AVP, the current time at QoS rule evaluation MUST be 235 within at least one of the time windows specified in one of the Time- 236 Of-Day-Condition AVPs. 238 When the Time-Of-Day-Condition AVP and Classifier AVP are present in 239 the same QoS-Rule AVP, both the time of day and packet classification 240 conditions MUST match for the QoS specification action to be applied. 242 4.1. Traffic Classifiers 244 Classifiers are used in many applications to specify how to select a 245 subset of data packets for subsequent treatment as indicated in the 246 action part of a rule. For example in a QoS application, if a packet 247 matches a classifier then that packet will be treated in accordance 248 with a QoS specification associated with that classifier. Figure 1 249 shows a typical deployment. 251 +-----------+ 252 +-----------+| 253 +--------+ +-------------+ +------------+|| 254 | | IN | | | ||| 255 | +--------->| +------------->| ||| 256 |Managed | | Classifying | | Unmanaged ||| 257 |Terminal| OUT | Entity | | Terminal ||| 258 | |<---------+ |<-------------+ ||+ 259 | | | | | |+ 260 +--------+ +-------------+ +------------+ 261 ^ 262 | Classifiers 263 | 264 +------+------+ 265 | | 266 | AAA | 267 | | 268 +-------------+ 270 Figure 1: Example of a Classifier Architecture 272 The managed terminal, the terminal for which the classifiers are 273 being specified is located on the left of the Classifying Entity. 274 The unmanaged terminals, the terminals that receive packets from the 275 Managed terminal or send packets to the managed terminal are located 276 to the right side of the Classifying Entity. 278 The Classifying Entity is responsible for classifying packets that 279 are incoming (IN) from the Managed Terminal or packets outgoing (OUT) 280 to the Managed Terminal. 282 A Classifier consists of a group of attributes that specify how to 283 match a packet. Each set of attributes expresses values about 284 aspects of the packet - typically the packet header. Different 285 protocols therefore would use different attributes. 287 In general a Classifier consists of the following: 289 Identifier: 291 The identifier uniquely identifies this classifier and may be used 292 to reference the classifier from another structure. 294 From: 296 Specifies the rule for matching the protocol specific source 297 address(es) part of the packet. 299 To: 301 Specifies the rule for matching the protocol specific destination 302 address(es) part of the packet. 304 Protocol: 306 Specifies the matching protocol of the packet. 308 Direction: 310 Specifies whether the classifier is to apply to packets flowing 311 from the Managed Terminal (IN) or to packets flowing to the 312 Managed Terminal (OUT), or packets flowing in both direction. 314 Options: 316 Attributes or properties associated with each protocol or layer, 317 or various values specific to the header of the protocol or layer. 318 Options allow matching on those values. 320 Each protocol type will have a specific set of attributes that can be 321 used to specify a classifier for that protocol. These attributes 322 will be grouped under a grouped AVP called a Classifier AVP. 324 4.1.1. Classifier AVP 326 The Classifier AVP (AVP Code TBD) is a grouped AVP that consists of a 327 set of attributes that specify how to match a packet. 329 Classifier ::= < AVP Header: XXX > 330 { Classifier-ID } 331 [ Protocol ] 332 [ Direction ] 333 * [ From-Spec ] 334 * [ To-Spec ] 335 * [ Diffserv-Code-Point ] 336 [ Fragmentation-Flag ] 337 * [ IP-Option ] 338 * [ TCP-Option ] 339 [ TCP-Flags ] 340 * [ ICMP-Type ] 341 * [ ETH-Option ] 342 * [ AVP ] 344 4.1.2. Classifier-ID AVP 346 The Classifier-ID AVP (AVP Code TBD) is of type OctetString and 347 uniquely identifies the classifier. Each application will define the 348 uniqueness scope of this identifier, e.g. unique per terminal or 349 globally unique. Exactly one Classifier-ID AVP MUST be contained 350 within a Classifier AVP. 352 4.1.3. Protocol AVP 354 The Protocol AVP (AVP Code TBD) is of type Enumerated and specifies 355 the protocol being matched. The attributes included in the 356 Classifier AVP MUST be consistent with the value of the Protocol AVP. 357 Exactly zero or one Protocol AVP may be contained within a Classifier 358 AVP. If the Protocol AVP is omitted from the Classifier, then 359 comparison of the protocol of the packet is irrelevant. The values 360 for this AVP are managed by IANA under the Protocol Numbers registry 361 as defined in [RFC2780]. 363 4.1.4. Direction AVP 365 The Direction AVP (AVP Code TBD) is of type Enumerated and specifies 366 in which direction to apply the Classifier. The values of the 367 enumeration are: "IN","OUT","BOTH". In the "IN" and "BOTH" 368 directions, the From-Spec refers to the address of the Managed 369 Terminal and the To-Spec refers to the unmanaged terminal. In the 370 "OUT" direction, the From-Spec refers to the Unmanaged Terminal 371 whereas the To-Spec refers to the Managed Terminal. If the Direction 372 AVP is omitted, the Classifier matches packets flowing in both 373 directions. 375 Value | Name and Semantic 376 ------+-------------------------------------------------- 377 0 | IN - The classifier applies to flows from the 378 | Managed Terminal. 379 1 | OUT - The classifier applies to flows to the 380 | Managed Terminal. 381 2 | BOTH - The classifier applies to flows both to 382 | and from the Managed Terminal. 384 4.1.5. From-Spec AVP 386 The From-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the 387 Source Specification used to match the packet. Zero or more of these 388 AVPs may appear in the Classifier. If this AVP is absent from the 389 Classifier then all packets are matched regardless of the source 390 address. If more than one instance of this AVP appears in the 391 Classifier then the source of the packet can match any From-Spec AVP. 392 The contents of this AVP are protocol specific. 394 If one instance (or multiple instances) of the IP address AVP (IP- 395 Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) 396 appear in the From-Spec AVP then the source IP address of the packet 397 MUST match one of the addresses represented by these AVPs. 399 If more that one instance of the layer 2 address AVPs (MAC-Address, 400 MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the 401 From-Spec then the the source layer 2 address of the packet MUST 402 match one of the addresses represented in these AVPs. 404 If more that one instance of the port AVPs (Port, Port-Range) appears 405 in the From-Spec AVP then the source port number MUST match one of 406 the port numbers represented in these AVPs. 408 If the IP address, MAC address and port AVPs appear in the same From- 409 Spec AVP then the source packet MUST match all the specifications, 410 i.e. match the IP address AND MAC address AND port number. 412 From-Spec ::= < AVP Header: XXX > 413 * [ IP-Address ] 414 * [ IP-Address-Range ] 415 * [ IP-Address-Mask ] 416 * [ MAC-Address ] 417 * [ MAC-Address-Mask] 418 * [ EUI64-Address ] 419 * [ EUI64-Address-Mask] 420 * [ Port ] 421 * [ Port-Range ] 422 [ Negated ] 423 [ Use-Assigned-Address ] 424 * [ AVP ] 426 4.1.6. To-Spec AVP 428 The To-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the 429 Destination Specification used to match the packet. Zero or more of 430 these AVPs may appear in the Classifier. If this AVP is absent from 431 the Classifier then all packets are matched regardless of the 432 destination address. If more than one instance of this AVP appears 433 in the Classifier then the destination of the packet can match any 434 To-Spec AVP. The contents of this AVP are protocol specific. 436 If one instance (or multiple instances) of the IP address AVP (IP- 437 Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) 438 appear in the To-Spec AVP then the destination IP address of the 439 packet MUST match one of the addresses represented by these AVPs. 441 If more that one instance of the layer 2 address AVPs (MAC-Address, 442 MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the 443 To-Spec then the the destination layer 2 address of the packet MUST 444 match one of the addresses represented in these AVPs. 446 If more that one instance of the port AVPs (Port, Port-Range) appears 447 in the To-Spec AVP then the destination port number MUST match one of 448 the port numbers represented in these AVPs. 450 If the IP address, MAC address and port AVPs appear in the same To- 451 Spec AVP then the destination packet MUST match all the 452 specifications, i.e. match the IP address AND MAC address AND port 453 number. 455 To-Spec ::= < AVP Header: XXX > 456 * [ IP-Address ] 457 * [ IP-Address-Range ] 458 * [ IP-Address-Mask ] 459 * [ MAC-Address ] 460 * [ MAC-Address-Mask] 461 * [ EUI64-Address ] 462 * [ EUI64-Address-Mask] 463 * [ Port ] 464 * [ Port-Range ] 465 [ Negated ] 466 [ Use-Assigned-Address ] 467 * [ AVP ] 469 4.1.7. Source and Destination AVPs 471 For packet classification the contents of the From-Spec and To-Spec 472 can contain the AVPs listed in the subsections below. 474 4.1.7.1. Negated AVP 476 The Negated AVP (AVP Code TBD) of type Enumerated containing the 477 values of True or False. Exactly zero or one of these AVPs may 478 appear in the From-Spec or To-Spec AVP. 480 When set to True the meaning of the match is inverted. Addresses 481 other than those in the To-Spec and From-Spec are to be matched 482 instead. When set to False, or when the AVP is not included then the 483 address specified To-Spec and From-Spec AVP are to be matched. 485 Note that the negation does not impact the port comparisons. 487 Value | Name 488 ------+-------- 489 0 | False 490 1 | True 492 4.1.7.2. IP-Address AVP 494 The IP-Address AVP (AVP Code TBD) is of type Address and specifies a 495 single IP address (IPv4 or IPv6) address to match. 497 4.1.7.3. IP-Address-Range AVP 499 The IP-Address-Range AVP (AVP Code TBD) is of type Grouped and 500 specifies an inclusive IP address range. 502 IP-Address-Range ::= < AVP Header: XXX > 503 [ IP-Address-Start ] 504 [ IP-Address-End ] 505 * [ AVP ] 507 If the IP-Address-Start AVP is not included then the address range 508 starts from the first valid IP address up to and including the 509 specified IP-Address-End address. 511 If the IP-Address-End AVP is not included then the address range 512 starts at the address specified by the IP-Address-Start AVP and 513 includes all the remaining valid IP addresses. 515 For the IP-Address-Range AVP to be valid, the IP-Address-Start AVP 516 MUST contain a value that is less than that of the IP-Address-End 517 AVP. 519 4.1.7.4. IP-Address-Start AVP 521 The IP-Address-Start AVP (AVP Code TBD) is of type Address and 522 specifies the first IP address (IPv4 or IPv6) address of an IP 523 address range. 525 4.1.7.5. IP-Address-End AVP 527 The IP-Address-End AVP (AVP Code TBD) is of type Address and 528 specifies the last IP address (IPv4 or IPv6) address of an address 529 range. 531 4.1.7.6. IP-Address-Mask AVP 533 The IP-Address-Mask AVP (AVP Code TBD) is of type Grouped and 534 specifies an IP address range using a base IP address and the bit- 535 width of the mask. For example, a range expressed as 192.0.2.0/24 536 will match all IP addresses from 192.0.2.0 up to and including 537 192.0.2.255. The bit-width MUST be valid for the type of IP address. 539 IP-Address-Mask ::= < AVP Header: XXX > 540 { IP-Address } 541 { IP-Bit-Mask-Width } 542 * [ AVP ] 544 4.1.7.7. IP-Mask-Bit-Mask-Width AVP 546 The IP-Bit-Mask-Width AVP (AVP Code TBD) is of type Unsigned32. The 547 value specifies the width of an IP address bit-mask. 549 4.1.7.8. MAC-Address AVP 551 The MAC-Address AVP (AVP Code TBD) is of type OctetString and 552 specifies a single layer 2 address in MAC-48 format. The value is a 553 6 octets encoding of the address as it would appear in the frame 554 header. 556 4.1.7.9. MAC-Address-Mask AVP 558 The MAC-Address-Mask AVP (AVP Code TBD) is of type Grouped and 559 specifies a set of MAC addresses using a bit mask to indicate the 560 bits of the MAC addresses which must fit to the specified MAC address 561 attribute. For example, a MAC-Address-Mask with the MAC-Address as 562 00-10-A4-23-00-00 and with a MAC-Address-Mask-Pattern of FF-FF-FF-FF- 563 00-00 will match all MAC addresses from 00-10-A4-23-00-00 up to and 564 including 00-10-A4-23-FF-FF. 566 MAC-Address-Mask ::= < AVP Header: XXX > 567 { MAC-Address } 568 { MAC-Address-Mask-Pattern } 569 * [ AVP ] 571 4.1.7.10. MAC-Address-Mask-Pattern AVP 573 The MAC-Address-Mask-Pattern AVP (AVP Code TBD) is of type 574 OctetString. The value is a 6 octets specifying the bit positions of 575 a MAC address, that are taken for matching. 577 4.1.7.11. EUI64-Address AVP 579 The EUI64-Address AVP (AVP Code TBD) is of type OctetString and 580 specifies a single layer 2 address in EUI-64 format. The value is a 581 8 octets encoding of the address as it would appear in the frame 582 header. 584 4.1.7.12. EUI64-Address-Mask AVP 586 The EUI64-Address-Mask AVP (AVP Code TBD) is of type Grouped and 587 specifies a set of EUI64 addresses using a bit mask to indicate the 588 bits of the EUI64 addresses which must fit to the specified EUI64 589 address attribute. For example, a EUI64-Address-Mask with the EUI64- 590 Address as 00-10-A4-FF-FE-23-00-00 and with a EUI64-Address-Mask- 591 Pattern of FF-FF-FF-FF-FF-FF-00-00 will match all EUI64 addresses 592 from 00-10-A4-FF-FE-23-00-00 up to and including 00-10-A4-FF-FE-23- 593 FF-FF. 595 EUI64-Address-Mask ::= < AVP Header: XXX > 596 { EUI64-Address } 597 { EUI64-Address-Mask-Pattern } 598 * [ AVP ] 600 4.1.7.13. EUI64-Address-Mask-Pattern AVP 602 The EUI64-Address-Mask-Pattern AVP (AVP Code TBD) is of type 603 OctetString. The value is a 8 octets specifying the bit positions of 604 a EUI64 address, that are taken for matching. 606 4.1.7.14. Port AVP 608 The Port AVP (AVP Code TBD) is of type Integer32 in the range of 0 to 609 65535 and specifies port numbers to match. The type of port is 610 indicated by the value of the Protocol AVP, i.e. if Procotol AVP 611 value is 6 (TCP) then the Port AVP represents a TCP port. 613 4.1.7.15. Port-Range AVP 615 The Port-Range AVP (AVP Code TBD) is of type Grouped and specifies an 616 inclusive range of ports. The type of the ports is indicated by the 617 value of the Protocol AVP, i.e. if Procotol AVP value is 6 (TCP) then 618 the Port-Range AVP represents an inclusive range of TCP ports. 620 Port-Range ::= < AVP Header: XXX > 621 [ Port-Start ] 622 [ Port-End ] 623 * [ AVP ] 625 If the Port-Start AVP is omitted then port 0 is assumed. If the 626 Port-End AVP is omitted then port 65535 is assumed. 628 4.1.7.16. Port-Start AVP 630 The Port-Start AVP (AVP Code TBD) is of type Integer32 and specifies 631 the first port number of an IP port range. 633 4.1.7.17. Port-End AVP 635 The Port-End AVP (AVP Code TBD) is of type Integer32 and specifies 636 the last port number of an IP port range. 638 4.1.7.18. Use-Assigned-Address AVP 640 In some scenarios, the AAA does not know the IP address assigned to 641 the Managed Terminal at the time that the Classifier is sent to the 642 Classifying Entity. The Use-Assigned-Address AVP (AVP Code TBD) is 643 of type Enumerated containing the values of True or False. When 644 present and set to True, it represents the IP address assigned to the 645 Managed Terminal. 647 Value | Name 648 ------+-------- 649 0 | False 650 1 | True 652 4.1.8. Header Option AVPs 654 The Classifier AVP may contain one or more of the following AVPs to 655 match on the various possible IP, TCP or ICMP header options. 657 4.1.8.1. Diffserv-Code-Point AVP 659 The Diffserv-Code-Point AVP (AVP Code TBD) is of type Enumerated and 660 specifies the Differentiated Services Field Codepoints to match in 661 the IP header. The values are managed by IANA under the 662 Differentiated Services Field Codepoints registry as defined in 663 [RFC2474]. 665 4.1.8.2. Fragmentation-Flag AVP 667 The Fragmentation-Flag AVP (AVP Code TBD) is of type Enumerated and 668 specifies the packet fragmentation flags to match in the IP header. 670 Value | Name and Semantic 671 ------+------------------------------------------------------------ 672 0 | Don't Fragment (DF) 673 1 | More Fragments (MF) 675 4.1.8.3. IP-Option AVP 677 The IP-Option AVP (AVP Code TBD) is of type Grouped and specifies an 678 IP header option that must be matched. 680 IP-Option ::= < AVP Header: XXX > 681 { IP-Option-Type } 682 * [ IP-Option-Value ] 683 [ Negated ] 684 * [ AVP ] 686 If one or more IP-Option-Value AVPs are present, one of the values 687 MUST match the value in the IP header option. If the IP-Option-Value 688 AVP is absent, the option type MUST be present in the IP header but 689 the value is wild carded. 691 The Negated AVP is used in conjunction with the IP-Option-Value AVPs 692 to specify IP header options which do not match specific values. The 693 Negated AVP is used without the IP-Option-Value AVP to specify IP 694 headers which do not contain the option type. 696 4.1.8.4. IP-Option-Type AVP 698 The IP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the 699 values are managed by IANA under the IP Option Numbers registry as 700 defined in [RFC2780]. 702 4.1.8.5. IP-Option-Value AVP 704 The IP-Option-Value AVP (AVP Code TBD) is of type OctetString and 705 contains the option value that must be matched. 707 4.1.8.6. TCP-Option AVP 709 The TCP-Option AVP (AVP Code TBD) is of type Grouped and specifies a 710 TCP header option that must be matched. 712 TCP-Option ::= < AVP Header: XXX > 713 { TCP-Option-Type } 714 * [ TCP-Option-Value ] 715 [ Negated ] 717 * [ AVP ] 719 If one or more TCP-Option-Value AVPs are present, one of the values 720 MUST match the value in the TCP header option. If the TCP-Option- 721 Value AVP is absent, the option type MUST be present in the TCP 722 header but the value is wild carded. 724 The Negated AVP is used in conjunction which the TCP-Option-Value 725 AVPs to specify TCP header options which do not match specific 726 values. The Negated AVP is used without the TCP-Option-Value AVP to 727 specify TCP headers which do not contain the option type. 729 4.1.8.7. TCP-Option-Type AVP 731 The TCP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the 732 values are managed by IANA under the TCP Option Numbers registry as 733 defined in [RFC2780]. 735 4.1.8.8. TCP-Option-Value AVP 737 The TCP-Option-Value AVP (AVP Code TBD) is of type OctetString and 738 contains the option value that must be matched. 740 4.1.8.9. TCP-Flags AVP 742 The TCP-Flags AVP (AVP Code TBD) is of type Grouped and specifies a 743 set of TCP control flags that must be matched. 745 TCP-Flags ::= < AVP Header: XXX > 746 { TCP-Flag-Type } 747 [ Negated ] 748 * [ AVP ] 750 If the Negated AVP is not present or present but set to False, the 751 TCP-Flag-Type AVP specifies which flags MUST be set. If the Negated 752 AVP is set to True, the TCP-Flag-Type AVP specifies which flags MUST 753 be cleared. 755 4.1.8.10. TCP-Flag-Type AVP 757 The TCP-Flag-Type AVP (AVP Code TBD) is of type Unsigned32 and 758 specifies the TCP control flag types that must be matched. The first 759 16 bits match the TCP header format defined in [RFC3168] and the 760 subsequent 16 bits are unused. Within the first 16 bits, bits 0 to 3 761 are unused and bits 4 to 15 are managed by IANA under the TCP Header 762 Flag registry as defined in [RFC3168]. 764 4.1.8.11. ICMP-Type 766 The ICMP-Type AVP (AVP Code TBD) is of type Grouped and specifies a 767 ICMP message type that must be matched. 769 ICMP-Type ::= < AVP Header: XXX > 770 { ICMP-Type-Number } 771 * [ ICMP-Code ] 772 [ Negated ] 773 * [ AVP ] 775 If the ICMP-Code AVP is present, the value MUST match that in the 776 ICMP header. If the ICMP-Code AVP is absent, the ICMP type MUST be 777 present in the ICMP header but the code is wild carded. 779 The Negated AVP is used in conjunction with the ICMP-Code AVPs to 780 specify ICMP codes that do not match specific values. The Negated 781 AVP is used without the ICMP-Code AVP to specify ICMP headers which 782 do not contain the ICMP type. As such, the Negated AVP feature 783 applies to ICMP-Code AVP if the ICMP-Code AVP is present. If the 784 ICMP-Code AVP is absent, the Negated AVP feature applies to the ICMP- 785 Type-Number. 787 4.1.8.12. ICMP-Type-Number AVP 789 The ICMP-Type-Number AVP (AVP Code TBD) is of type Enumerated and the 790 values are managed by IANA under the ICMP Type Numbers registry as 791 defined in [RFC2780]. 793 4.1.8.13. ICMP-Code AVP 795 The ICMP-Code AVP (AVP Code TBD) is of type Enumerated and the values 796 are managed by IANA under the ICMP Type Numbers registry as defined 797 in [RFC2780]. 799 4.1.8.14. ETH-Option AVP 801 The ETH-Option AVP (AVP Code TBD) is of type Grouped and specifies 802 Ethernet specific attributes. 804 ETH-Option ::= < AVP Header: XXX > 805 { ETH-Proto-Type } 806 * [ VLAN-ID-Range ] 807 * [ User-Priority-Range ] 808 * [ AVP ] 810 4.1.8.15. ETH-Proto-Type AVP 812 The Eth-Proto-Type AVP (AVP Code TBD) is of type Grouped and 813 specifies the encapsulated protocol type. ETH-Ether-Type and ETH-SAP 814 are mutually exclusive. 816 ETH-Proto-Type ::= < AVP Header: XXX > 817 * [ ETH-Ether-Type ] 818 * [ ETH-SAP ] 819 * [ AVP ] 821 4.1.8.16. ETH-Ether-Type AVP 823 The ETH-Ether-Type AVP (AVP Code TBD) is of type OctetString. The 824 value is a double octet that contains the value of the Ethertype 825 field in the packet to match. This AVP MAY be present in the case of 826 DIX or if SNAP is present at 802.2 but the ETH-SAP AVP MUST NOT be 827 present in this case. 829 4.1.8.17. ETH-SAP AVP 831 The ETH-SAP AVP (AVP Code TBD) is of type OctetString. The value is 832 a double octet representing the 802.2 SAP as specified in 833 [IEEE802.2]. The first octet contains the DSAP and the second the 834 SSAP. 836 4.1.8.18. VLAN-ID-Range AVP 838 The VLAN-ID-Range AVP (AVP Code TBD) is of type Grouped and specifies 839 the VLAN range to match. VLAN identities are either specified by a 840 single VLAN-ID according to [IEEE802.1Q] or by a combination of 841 Customer and Service VLAN-IDs according to [IEEE802.1ad]. 843 The single VLAN-ID is represented by the C-VID-Start and C-VID-End 844 AVPs and the S-VID-Start and S-VID-End AVPs SHALL be ommitted in this 845 case. If the VLAN-ID-Range AVP is omitted from the Classifier, then 846 comparison of the VLAN identity of the packet is irrelevant. 848 VLAN-ID-Range ::= < AVP Header: XXX > 849 [ S-VID-Start ] 850 [ S-VID-End ] 851 [ C-VID-Start ] 852 [ C-VID-End ] 853 * [ AVP ] 855 The following is the list of possible combinations of the S-VID-Start 856 and S-VID-End AVPs and their inference: 858 o If S-VID-Start AVP is present but the S-VID-End AVP is absent, the 859 S-VID-Start AVP value MUST equal the value of the IEEE 802.1ad 860 S-VID bits specified in [IEEE802.1ad] for a successful match. 861 o If S-VID-Start AVP is absent but the S-VID-End AVP is present, the 862 S-VID-End AVP value MUST equal the value of the IEEE 802.1ad S-VID 863 bits for a successful match. 864 o If both S-VID-Start and S-VID-End AVPs are present and their 865 values are equal, the S-VID-Start AVP value MUST equal the value 866 of the IEEE 802.1ad S-VID bits for a successful match. 867 o If both S-VID-Start and S-VID-End AVPs are present and the value 868 of S-VID-End AVP is greater than the value of the S-VID-Start AVP, 869 the value of the IEEE 802.1ad S-VID bits MUST be greater than or 870 equal to the S-VID- Start AVP value and less than or equal to the 871 S-VID-End AVP value for a successful match. If the S-VID-Start 872 and S-VID-End AVPs are specified, then Ethernet packets without 873 IEEE 802.1ad encapsulation MUST NOT match this Classifier. 874 o If the S-VID-Start and S-VID-End AVPs are omitted, then existence 875 of IEEE802.1ad encapsulation or comparison of the IEEE 802.1ad 876 S-VID bits is irrelevant for this Classifier. 878 The following is the list of possible combinations of the C-VID-Start 879 and C-VID-End AVPs and their inference: 881 o If C-VID-Start AVP is present but the C-VID-End AVP is absent, the 882 C-VID-Start AVP value MUST equal the value of the IEEE 802.1ad 883 C-VID bits specified in [IEEE802.1ad] or the IEEE 802.1Q VLAN-ID 884 bits specified in [IEEE802.1Q] for a successful match. 885 o If C-VID-Start AVP is absent but the C-VID-End AVP is present, the 886 C-VID-End AVP value MUST equal the value of the IEEE 802.1ad C-VID 887 bits or the IEEE 802.1Q VLAN-ID bits for a successful match. 888 o If both C-VID-Start and C-VID-End AVPs are present and their 889 values are equal, the C-VID-Start AVP value MUST equal the value 890 of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits for 891 a successful match. 892 o If both C-VID-Start and C-VID-End AVPs are present and the value 893 of C-VID-End AVP is greater than the value of the C-VID-Start AVP, 894 the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q 895 VLAN-ID bits MUST be greater than or equal to the C-VID-Start AVP 896 value and less than or equal to the C-VID-End AVP value for a 897 successful match. If the C-VID-Start and C-VID-End AVPs are 898 specified, then Ethernet packets without IEEE 802.1ad or IEEE 899 802.1Q encapsulation MUST NOT match this Classifier. 900 o If the C-VID-Start and C-VID-End AVPs are omitted, the comparison 901 of the IEEE 802.1ad C-VID bits or IEEE 802.1Q VLAN-ID bits for 902 this Classifier is irrelevant. 904 4.1.8.19. S-VID-Start AVP 906 The S-VID-Start AVP (AVP Code TBD) is of type Unsigned32. The value 907 MUST be in the range from 0 to 4095. The value of this AVP specifies 908 the start value of the range of S-VID VLAN-IDs to be matched. 910 4.1.8.20. S-VID-End AVP 912 The S-VID-End AVP (AVP Code TBD) is of type Unsigned32. The value 913 MUST be in the range from 0 to 4095. The value of this AVP specifies 914 the end value of the range of S-VID VLAN-IDs to be matched. 916 4.1.8.21. C-VID-Start AVP 918 The C-VID-Start AVP (AVP Code TBD) is of type Unsigned32. The value 919 MUST be in the range from 0 to 4095. The value of this AVP specifies 920 the start value of the range of C-VID VLAN-IDs to be matched. 922 4.1.8.22. C-VID-End AVP 924 The C-VID-End AVP (AVP Code TBD) is of type Unsigned32. The value 925 MUST be in the range from 0 to 4095. The value of this AVP specifies 926 the end value of the range of C-VID VLAN-IDs to be matched. 928 4.1.8.23. User-Priority-Range AVP 930 The User-Priority-Range AVP (AVP Code TBD) is of type Grouped and 931 specifies an inclusive range to match the user_priority parameter 932 specified in [IEEE802.1D]. An Ethernet packet containing the 933 user_priority parameter matches this Classifier if the value is 934 greater than or equal to Low-User-Priority and less than or equal to 935 High-User-Priority. If this AVP is omitted, then comparison of the 936 IEEE 802.1D user_priority parameter for this Classifier is 937 irrelevant. 939 User-Priority-Range ::= < AVP Header: XXX > 940 * [ Low-User-Priority ] 941 * [ High-User-Priority ] 942 * [ AVP ] 944 4.1.8.24. Low-User-Priority AVP 946 The Low-User-Priority AVP (AVP Code TBD) is of type Unsigned32. The 947 value MUST be in the range from 0 to 7. 949 4.1.8.25. High-User-Priority AVP 951 The High-User-Priority AVP (AVP Code TBD) is of type Unsigned32. The 952 value MUST be in the range from 0 to 7. 954 4.2. Time Of Day AVPs 956 In many QoS applications, the QoS specification applied to the 957 traffic flow is conditional upon the time of day when the flow was 958 observed. The following sections define AVPs that can be used to 959 express one or more time windows which determine when a QoS 960 specification is applicable to a traffic flow. 962 4.2.1. Time-Of-Day-Condition AVP 964 The Time-Of-Day-Condition AVP (AVP Code TBD) is of type Grouped and 965 specifies one or more time windows. 967 Time-Of-Day-Condition ::= < AVP Header: XXX > 968 [ Time-Of-Day-Start ] 969 [ Time-Of-Day-End ] 970 [ Day-Of-Week-Mask ] 971 [ Day-Of-Month-Mask ] 972 [ Month-Of-Year-Mask ] 973 [ Absolute-Start-Time ] 974 [ Absolute-End-Time ] 975 [ Timezone-Flag ] 976 * [ AVP ] 978 For example, a time window for 9am to 5pm (local time) from Monday to 979 Friday would be expressed as: 981 Time-Of-Day-Condition = { 982 Time-Of-Day-Start = 32400; 983 Time-Of-Day-End = 61200; 984 Day-Of-Week-Mask = 985 ( MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY ); 986 Timezone-Flag = LOCAL; 987 } 989 4.2.2. Time-Of-Day-Start AVP 991 The Time-Of-Day-Start AVP (AVP Code TBD) is of type Unsigned32. The 992 value MUST be in the range from 0 to 86400. The value of this AVP 993 specifies the start of an inclusive time window expressed as the 994 offset in seconds from midnight. If this AVP is absent from the 995 Time-Of-Day-Condition AVP, the time window starts at midnight. 997 4.2.3. Time-Of-Day-End AVP 999 The Time-Of-Day-End AVP (AVP Code TBD) is of type Unsigned32. The 1000 value MUST be in the range from 1 to 86400. The value of this AVP 1001 specifies the end of an inclusive time window expressed as the offset 1002 in seconds from midnight. If this AVP is absent from the Time-Of- 1003 Day-Condition AVP, the time window ends one second before midnight. 1005 4.2.4. Day-Of-Week-Mask AVP 1007 The Day-Of-Week-Mask AVP (AVP Code TBD) is of type Unsigned32. The 1008 value is a bitmask which specifies the day of the week for the time 1009 window to match. This document specifies the following bits: 1011 Bit | Name 1012 ------+------------ 1013 0 | SUNDAY 1014 1 | MONDAY 1015 2 | TUESDAY 1016 3 | WEDNESDAY 1017 4 | THURSDAY 1018 5 | FRIDAY 1019 6 | SATURDAY 1021 The bit MUST be set for the time window to match on the corresponding 1022 day of the week. Bit 0 is the most significant bit and unused bits 1023 MUST be cleared. If this AVP is absent from the Time-Of-Day- 1024 Condition AVP, the time windows match on all days of the week. 1026 4.2.5. Day-Of-Month-Mask AVP 1028 The Day-Of-Month AVP (AVP Code TBD) is of type Unsigned32. The value 1029 MUST be in the range from 0 to 2147483647. The value is a bitmask 1030 which specifies the days of the month where bit 0 represents the 1031 first day of the month through to bit 30 which represents the last 1032 day of the month. The bit MUST be set for the time window to match 1033 on the corresponding day of the month. Bit 0 is the most significant 1034 bit and unused bits MUST be cleared. If this AVP is absent from the 1035 Time-Of-Day-Condition AVP, the time windows match on all days of the 1036 month. 1038 4.2.6. Month-Of-Year-Mask AVP 1040 The Month-Of-Year-Mask AVP (AVP Code TBD) is of type Unsigned32. The 1041 value is a bitmask which specifies the months of the year for the 1042 time window to match. This document specifies the following bits: 1044 Bit | Name 1045 ------+----------- 1046 0 | JANUARY 1047 1 | FEBRUARY 1048 2 | MARCH 1049 3 | APRIL 1050 4 | MAY 1051 5 | JUNE 1052 6 | JULY 1053 7 | AUGUST 1054 8 | SEPTEMBER 1055 9 | OCTOBER 1056 10 | NOVEMBER 1057 11 | DECEMBER 1059 The bit MUST be set for the time window to match on the corresponding 1060 month of the year. Bit 0 is the most significant bit and unused bits 1061 MUST be cleared. If this AVP is absent from the Time-Of-Day- 1062 Condition AVP, the time windows match during all months of the year. 1064 4.2.7. Absolute-Start-Time AVP 1066 The Absolute-Start-Time AVP (AVP Code TBD) is of type Time. The 1067 value of this AVP specifies the time in seconds since January 1, 1068 1900, 00:00 UTC when the time window starts. If this AVP is absent 1069 from the Time-Of-Day-Condition AVP, the time window starts on January 1070 1, 1900, 00:00 UTC. 1072 4.2.8. Absolute-Start-Fractional-Seconds AVP 1074 The Absolute-Start-Fractional-Seconds AVP (AVP Code TBD) is of type 1075 Unsigned32. The value specifies the fractional seconds that are 1076 added to Absolute-Start-Time value in order to deterimine when the 1077 time window starts. If this AVP is absent from the Time-Of-Day- 1078 Condition AVP then the fractional seconds are assumed to be zero. 1080 4.2.9. Absolute-End-Time AVP 1082 The Time-Of-Day-End AVP (AVP Code TBD) is of type Time. The value of 1083 this AVP specifies the time in seconds since January 1, 1900, 00:00 1084 UTC when the time window ends. If this AVP is absent from the Time- 1085 Of-Day-Condition AVP, the time window is open-ended. 1087 4.2.10. Absolute-End-Fractional-Seconds AVP 1089 The Absolute-End-Fractional-Seconds AVP (AVP Code TBD) is of type 1090 Unsigned32. The value specifies the fractional seconds that are 1091 added to Absolute-End-Time value in order to deterimine when the time 1092 window ends. If this AVP is absent from the Time-Of-Day-Condition 1093 AVP then the fractional seconds are assumed to be zero. 1095 4.2.11. Timezone-Flag AVP 1097 The Timezone-Flag AVP (AVP Code TBD) is of type Enumerated and 1098 indicates whether the time windows are specified in UTC, local time 1099 at the managed terminal or as an offset from UTC. If this AVP is 1100 absent from the Time-Of-Day-Condition AVP, the time windows are in 1101 UTC. 1103 This document defines the following values: 1105 Value | Name and Semantic 1106 ------+-------------------------------------------------- 1107 0 | UTC - The time windows are expressed in UTC. 1108 1 | LOCAL - The time windows are expressed in local 1109 | time at the Managed Terminal. 1110 2 | OFFSET - The time windows are expressed as an 1111 | offset from UTC (see Timezone-Offset AVP). 1113 4.2.12. Timezone-Offset AVP 1115 The Timezone-Offset AVP (AVP Code TBD) is of type Integer32. The 1116 value of this AVP MUST be in the range from -43200 to 43200. It 1117 specifies the offset in seconds from UTC that was used to express 1118 Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month- 1119 Mask and Month-Of-Year-Mask AVPs. This AVP MUST be present if the 1120 Timezone-Flag AVP is set to OFFSET. 1122 5. Actions 1124 This section defines the actions associated with a rule. This 1125 document only defines QoS specific actions but further actions can be 1126 specified as extensions. 1128 5.1. QoS-Action AVP 1130 The QoS-Action AVP (AVP Code TBD) is of type Enumerated and lists the 1131 actions that are associated with the condition part of a rule. The 1132 following actions are defined in this document: 1134 0: drop 1135 1: shape 1136 2: mark 1138 drop: 1140 All traffic that is met by the condition part of a rule MUST be 1141 dropped. This action implements firewalling functionality. 1143 shape: 1145 [RFC2475] describes shaping as "the process of delaying packets 1146 within a traffic stream to cause it to conform to some defined 1147 traffic profile". When the action is set to 'shape', it is 1148 expected that the QoS-Parameters AVP carries QoS information to 1149 indicate how to shape the traffic indicated in the condition part 1150 of the rule. 1152 mark: 1154 [RFC2475] describes marking as "the process of setting the DS 1155 codepoint in a packet based on defined rules". When the action is 1156 set to 'mark', it is expected that the QoS-Parameters AVP carries 1157 information about the DiffServ marking. 1159 Further action values can be registered, as described in 1160 Section 10.3. 1162 [RFC2475] also describes an action called "policing" as "the process 1163 of discarding packets (by a dropper) within a traffic stream in 1164 accordance with the state of a corresponding meter enforcing a 1165 traffic profile". This behavior in modeled in the QoS-Rule through 1166 the inclusion of the Excess-Treatment AVP containing a QoS-Action AVP 1167 set to "drop". 1169 5.2. QoS-Profile-Id AVP 1171 The QoS-Profile-Id AVP (AVP Code TBD) is of type Unsigned32 and 1172 contains a QoS profile template identifier. An initial QoS profile 1173 template is defined with value of 0 and can be found in 1174 [I-D.ietf-dime-qos-parameters]. The registry for the QoS profile 1175 templates is created with the same document. 1177 5.3. QoS-Profile-Template AVP 1179 The QoS-Profile-Template AVP (AVP Code TBD) is of type Grouped and 1180 defines the namespace of the QoS profile (indicated in the Vendor-ID 1181 AVP) followed by the specific value for the profile. 1183 The Vendor-Id AVP contains a 32 bit IANA Private Enterprise Number 1184 (PEN) and the QoS-Profile-Id AVP contains the template identifier 1185 assigned by the vendor. The vendor identifier of zero (0) is used 1186 for the IETF. 1188 QoS-Profile-Template ::= < AVP Header: XXX > 1189 { Vendor-Id } 1190 { QoS-Profile-Id } 1191 * [ AVP ] 1193 5.4. QoS-Semantics 1195 The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and 1196 provides the semantics for the QoS-Profile-Template and QoS- 1197 Parameters AVPs in the QoS-Rule AVP. 1199 This document defines the following values: 1201 (0): QoS-Desired 1202 (1): QoS-Available 1203 (2): QoS-Reserved 1204 (3): Minimum-QoS 1205 (4): QoS-Authorized 1207 The semantic of the QoS parameters depend on the information provided 1208 in the list above. The semantics of the different values are as 1209 follows: 1211 Object Type Direction Semantic 1212 --------------------------------------------------------------------- 1213 QoS-Desired C->S Please authorize the indicated QoS 1214 QoS-Desired C<-S NA 1215 QoS-Available C->S Admission Control at interface indicates 1216 that this QoS is available. (note 1) 1217 QoS-Available C<-S Indicated QoS is available. (note 2) 1218 QoS-Reserved C->S Used for reporting during accounting. 1219 QoS-Reserved C<-S NA 1220 Minimum-QoS C->S Indicates that the client is not 1221 interested in authorizing QoS that is 1222 lower than Min. QoS. 1223 Minimum-QoS C<-S The client must not provide QoS 1224 guarantees lower than Min. QoS. 1225 QoS-Authorized C->S NA 1226 QoS-Authorized C<-S Indicated QoS authorized 1228 Legend: 1230 C: Diameter client 1231 S: Diameter server 1232 NA: Not applicable to this document; 1233 no semantic defined in this specification 1235 Notes: 1237 (1) QoS-Available is only useful in relationship with QoS-Desired 1238 (and optionally with Minimum-QoS). 1239 (2) QoS-Available is only useful when the AAA server performs 1240 admission control and knows about the resources in the network. 1242 5.5. QoS-Parameters AVP 1244 The QoS-Parameters AVP (AVP Code TBD) is of type grouped and contains 1245 Quality of Service parameters. These parameters are defined in 1246 separate documents and depend on the indicated QoS profile template 1247 of the QoS-Profile-Template AVP. For an initial QoS parameter 1248 specification see [I-D.ietf-dime-qos-parameters]. 1250 QoS-Parameters ::= < AVP Header: XXX > 1251 * [ AVP ] 1253 5.6. Excess-Treatment AVP 1255 The Excess-Treatment AVP (AVP Code TBD) is of type grouped and 1256 indicates how out-of-profile traffic, i.e. traffic not covered by the 1257 original QoS-Profile-Template and QoS-Parameters AVPs, is treated. 1259 The additional QoS-Action, QoS-Profile-Template and QoS-Parameters 1260 AVPs carried inside the Excess-Treatment AVP provide information 1261 about the QoS treatment of the excess traffic. In case the Excess- 1262 Treatment AVP is absent then the treatment of the out-of-profile 1263 traffic is left to the discretion of the node performing QoS 1264 treatment. 1266 Excess-Treatment ::= < AVP Header: XXX > 1267 { QoS-Action } 1268 [ QoS-Profile-Template ] 1269 [ QoS-Parameters ] 1270 * [ AVP ] 1272 6. QoS Capability Indication 1274 The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains 1275 a list of supported Quality of Service profile templates (and 1276 therefore the support of the respective parameter AVPs). 1278 The QoS-Capability AVP may be used for a simple announcement of the 1279 QoS capabilities and QoS profiles supported by a peer. It may also 1280 be used to negotiate a mutually supported set of QoS capabilities and 1281 QoS profiles between two peers. In such a case, handling of failed 1282 negotiations is application and/or deployment specific. 1284 QoS-Capability ::= < AVP Header: XXX > 1285 1*{ QoS-Profile-Template } 1286 * [ AVP ] 1288 The QoS-Profile-Template AVP is defined in Section 5.3. 1290 7. Examples 1292 This section shows a number of signaling flows where QoS negotiation 1293 and authorization is part of the conventional NASREQ, EAP or Credit 1294 Control applications message exchanges. The signalling flows for the 1295 Diameter QoS Application are described in 1296 [I-D.ietf-dime-diameter-qos]. 1298 7.1. Diameter EAP with QoS Information 1300 Figure 2 shows a simple signaling flow where a NAS (Diameter Client) 1301 announces its QoS awareness and capabilities included into the DER 1302 message and as part of the access authentication procedure. Upon 1303 completion of the EAP exchange, the Diameter Server provides a pre- 1304 provisioned QoS profile with the QoS-Semantics in the QoS-Rule AVP 1305 set to "QoS-Authorized", to the NAS in the final DEA message. 1307 End Diameter Diameter 1308 Host Client Server 1309 | | | 1310 | (initiate EAP) | | 1311 |<----------------------------->| | 1312 | | Diameter-EAP-Request | 1313 | | EAP-Payload(EAP Start) | 1314 | | QoS-Capability | 1315 | |------------------------------->| 1316 | | | 1317 | | Diameter-EAP-Answer | 1318 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 1319 | | EAP-Payload(EAP Request #1) | 1320 | |<-------------------------------| 1321 | EAP Request(Identity) | | 1322 |<------------------------------| | 1323 : : : 1324 : <<>> : 1325 : : : 1326 | | | 1327 | EAP Response #N | | 1328 |------------------------------>| | 1329 | | Diameter-EAP-Request | 1330 | | EAP-Payload(EAP Response #N) | 1331 | |------------------------------->| 1332 | | | 1333 | | Diameter-EAP-Answer | 1334 | | Result-Code=DIAMETER_SUCCESS | 1335 | | EAP-Payload(EAP Success) | 1336 | | (authorization AVPs) | 1337 | | QoS-Resources(QoS-Authorized) | 1338 | |<-------------------------------| 1339 | | | 1340 | EAP Success | | 1341 |<------------------------------| | 1342 | | | 1344 Figure 2: Example of a Diameter EAP enhanced with QoS Information 1346 7.2. Diameter NASREQ with QoS Information 1348 Figure 3 shows a similar pre-provisioned QoS signaling as in Figure 2 1349 but using the NASREQ application instead of EAP application. 1351 End Diameter 1352 Host NAS Server 1353 | | | 1354 | Start Network | | 1355 | Attachment | | 1356 |<---------------->| | 1357 | | | 1358 | |AA-Request | 1359 | |NASREQ-Payload | 1360 | |QoS-Capability | 1361 | +----------------------------->| 1362 | | | 1363 | | AA-Answer| 1364 | Result-Code=DIAMETER_MULTI_ROUND_AUTH| 1365 | NASREQ-Payload(NASREQ Request #1)| 1366 | |<-----------------------------+ 1367 | | | 1368 | Request | | 1369 |<-----------------+ | 1370 | | | 1371 : : : 1372 : <<>> : 1373 : : : 1374 | Response #N | | 1375 +----------------->| | 1376 | | | 1377 | |AA-Request | 1378 | |NASREQ-Payload ( Response #N )| 1379 | +----------------------------->| 1380 | | | 1381 | | AA-Answer| 1382 | | Result-Code=DIAMETER_SUCCESS| 1383 | | (authorization AVPs)| 1384 | | QoS-Resources(QoS-Authorized)| 1385 | |<-----------------------------+ 1386 | | | 1387 | Success | | 1388 |<-----------------+ | 1389 | | | 1391 Figure 3: Example of a Diameter NASREQ enhanced with QoS Information 1393 7.3. QoS Authorization 1395 Figure 4 shows an example of authorization only QoS signaling as part 1396 of the NASREQ message exchange. The NAS provides the Diameter server 1397 with the "QoS-Desired" QoS-Semantics AVP included in the QoS- 1398 Resources AVP. The Diameter server then either authorizes the 1399 indicated QoS or rejects the request and informs the NAS about the 1400 result. In this scenario the NAS does not need to include the QoS- 1401 Capability AVP in the AAR message as the QoS-Resources AVP implicitly 1402 does the same and also the NAS is authorizing a specific QoS profile, 1403 not a pre-provisioned one. 1405 End Diameter 1406 Host NAS Server 1407 | | | 1408 | | | 1409 | QoS Request | | 1410 +----------------->| | 1411 | | | 1412 | |AA-Request | 1413 | |Auth-Request-Type=AUTHORIZE_ONLY 1414 | |NASREQ-Payload | 1415 | |QoS-Resources(QoS-Desired) | 1416 | +----------------------------->| 1417 | | | 1418 | | AA-Answer| 1419 | | NASREQ-Payload(Success)| 1420 | | QoS-Resources(QoS-Authorized)| 1421 | |<-----------------------------+ 1422 | Accept | | 1423 |<-----------------+ | 1424 | | | 1425 | | | 1426 | | | 1428 Figure 4: Example of an Authorization-Only Message Flow 1430 7.4. Diameter Server Initiated Re-authorization of QoS 1432 Figure 5 shows a message exchange for a Diameter server initiated QoS 1433 re-authorization procedure. The Diameter server sends the NAS a RAR 1434 message requesting re-authorization for an existing session and the 1435 NAS acknowledges it with a RAA message. The NAS is aware of its 1436 existing QoS profile and information for the ongoing session that the 1437 Diameter server requested for re-authorization. Thus, the NAS must 1438 initiate re-authorization of the existing QoS profile. The re- 1439 authorization procedure is the same as in Figure 4. 1441 End Diameter 1442 Host NAS Server 1443 | | | 1444 | | | 1445 : : : 1446 : <<>> : 1447 : : : 1448 | | | 1449 | | RA-Request | 1450 | |<-----------------------------+ 1451 | | | 1452 | |RA-Answer | 1453 | |Result-Code=DIAMETER_SUCCESS | 1454 | +----------------------------->| 1455 | | | 1456 | | | 1457 | |AA-Request | 1458 | |NASREQ-Payload | 1459 | |Auth-Request-Type=AUTHORIZE_ONLY 1460 | |QoS-Resources(QoS-Desired) | 1461 | +----------------------------->| 1462 | | | 1463 | | AA-Answer| 1464 | | Result-Code=DIAMETER_SUCCESS| 1465 | | (authorization AVPs)| 1466 | | QoS-Resources(QoS-Authorized)| 1467 | |<-----------------------------+ 1468 | | | 1470 Figure 5: Example of a Server-initiated Re-Authorization Procedure 1472 7.5. Diameter Credit Control with QoS Information 1474 In this case the User is charged as soon as the Service Element (CC 1475 client) receives the service request. In this case the client uses 1476 the "QoS-Desired" QoS-Semantics parameter in the QoS-Resources AVP 1477 that it sends to the Accounitng server. The server responds with a 1478 "QoS-Available" QoS-Semantics parameter in the QoS-Resources AVP 1479 Service Element 1480 End User (CC Client) B CC Server 1481 | | | | 1482 |(1) Service Request | | | 1483 |-------------------->| | | 1484 | |(2) CCR (event, DIRECT_DEBITING,| 1485 | | QoS-Resources(QoS-desired)) | 1486 | |-------------------------------->| 1487 | |(3) CCA (Granted-Units, QoS- | 1488 | | Resources(QoS-Authorized)) | 1489 | |<--------------------------------| 1490 |(4) Service Delivery | | | 1491 |<--------------------| | | 1492 |(5) Begin service | | | 1493 |<------------------------------------>| | 1494 | | | | 1495 . . . . 1496 . . . . 1498 Figure 6: Example for a One-Time Diameter Credit Control Charging 1499 Event 1501 7.6. Classifier Examples 1503 Example: Classify all packets from hosts on subnet 192.0.2.0/24 to 1504 ports 80, 8090 or 443 on web servers 192.0.2.123, 192.0.2.124, 1505 192.0.2.125. 1507 Classifier = { 1508 Classifier-Id = "web_svr_example"; 1509 Protocol = TCP; 1510 Direction = OUT; 1511 From-Spec = { 1512 IP-Address-Mask = { 1513 IP-Address = 192.0.2.0; 1514 IP-Bit-Mask-Width = 24; 1515 } 1516 } 1517 To-Spec = { 1518 IP-Address = 192.0.2.123; 1519 IP-Address = 192.0.2.124; 1520 IP-Address = 192.0.2.125; 1521 Port = 80; 1522 Port = 8080; 1523 Port = 443; 1524 } 1525 } 1526 Example: Any SIP signalling traffic from a device with a MAC address 1527 of 01:23:45:67:89:ab to servers with IP addresses in the range 1528 192.0.2.90 to 192.0.2.190. 1530 Classifier = { 1531 Classifier-Id = "web_svr_example"; 1532 Protocol = UDP; 1533 Direction = OUT; 1534 From-Spec = { 1535 MAC-Address = 01:23:45:67:89:ab; 1536 } 1537 To-Spec = { 1538 IP-Address-Range = { 1539 IP-Address-Start = 192.0.2.90; 1540 IP-Address-End = 192.0.2.190; 1541 } 1542 Port = 5060; 1543 Port = 3478; 1544 Port-Range = { 1545 Port-Start = 16348; 1546 Port-End = 32768; 1547 } 1548 } 1549 } 1551 7.7. QoS Examples 1553 The following high level description aims to illustrate the 1554 interworking between the Diameter QoS AVPs defined in this document 1555 and the QoS parameters defined in [I-D.ietf-dime-qos-parameters]. 1557 Consider the following example where a rule should be installed that 1558 limits traffic to 1 Mbit/sec and where out-of-profile traffic shall 1559 be dropped.The Classifers are ignored in this example. 1561 This would require the QoS-Action AVP to be set to 'shape' and the 1562 QoS-Parameters AVP carries the Bandwidth AVP indicating the 1 Mbit/ 1563 sec limit. The QoS-Action carried inside the Excess-Treatment AVP 1564 would be set to 'drop'. 1566 In a second, more complex scenario, we consider traffic marking with 1567 DiffServ. In-profile traffic (of 5 Mbits/sec in our example) shall 1568 be associated with a particular PHB-Class "X". Out-of-profile 1569 traffic shall belong to a different PHB-Class, in our example "Y". 1571 This configuration would require the QoS-Action AVP to be set to 1572 'mark'. The QoS-Parameters AVPs for the traffic conforming of the 1573 profile contains two AVPs, namely the TMOD-1 AVP and the PHB-Class 1574 AVP. The TMOD-1 AVP describes the traffic characteristics, namely 5 1575 Mbit/sec, and the PHB-Class AVP is set to class "X". Then, the 1576 Excess-Treatment AVP has to be included with the QoS-Action AVP set 1577 to 'mark' and the QoS-Parameters AVP to carry another PHB-Class AVP 1578 indicating PHB-Class AVP setting to class "Y". 1580 8. Acknowledgments 1582 We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, 1583 Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Tolga 1584 Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina Tsou, 1585 Pete McCann, Georgios Karagiannis, Elwyn Davies, Max Riegel and Yong 1586 Li for their comments. We thank Victor Fajardo for his job as PROTO 1587 document shepherd. 1589 9. Contributors 1591 Max Riegel contributed the VLAN sections. 1593 10. IANA Considerations 1595 10.1. AVP Codes 1597 IANA is requested to allocate codes from the "AVP Codes" registry 1598 under Authentication, Authorization, and Accounting (AAA) Parameters 1599 for the following AVPs that are defined in this document. 1601 +--------------------------------------------------------------------+ 1602 | AVP Section | 1603 | Attribute Name Code Defined Data Type | 1604 +--------------------------------------------------------------------+ 1605 |QoS-Resources TBD 3.1 Grouped | 1606 |QoS-Rule TBD 3.2 Grouped | 1607 |QoS-Rule-Precedence TBD 3.3 Unsigned32 | 1608 |Classifier TBD 4.1.1 Grouped | 1609 |Classifier-ID TBD 4.1.2 OctetString | 1610 |Protocol TBD 4.1.3 Enumerated | 1611 |Direction TBD 4.1.4 Enumerated | 1612 |From-Spec TBD 4.1.5 Grouped | 1613 |To-Spec TBD 4.1.6 Grouped | 1614 |Negated TBD 4.1.7.1 Enumerated | 1615 |IP-Address TBD 4.1.7.2 Address | 1616 |IP-Address-Range TBD 4.1.7.3 Grouped | 1617 |IP-Address-Start TBD 4.1.7.4 Address | 1618 |IP-Address-End TBD 4.1.7.5 Address | 1619 |IP-Address-Mask TBD 4.1.7.6 Grouped | 1620 |IP-Mask-Bit-Mask-Width TBD 4.1.7.7 Unsigned32 | 1621 |MAC-Address TBD 4.1.7.8 OctetString | 1622 |MAC-Address-Mask TBD 4.1.7.9 Grouped | 1623 |MAC-Address-Mask-Pattern TBD 4.1.7.10 OctetString | 1624 |EUI64-Address TBD 4.1.7.11 OctetString | 1625 |EUI64-Address-Mask TBD 4.1.7.12 Grouped | 1626 |EUI64-Address-Mask-Pattern TBD 4.1.7.13 OctetString | 1627 |Port TBD 4.1.7.14 Integer32 | 1628 |Port-Range TBD 4.1.7.15 Grouped | 1629 |Port-Start TBD 4.1.7.16 Integer32 | 1630 |Port-End TBD 4.1.7.17 Integer32 | 1631 |Use-Assigned-Address TBD 4.1.7.18 Enumerated | 1632 |Diffserv-Code-Point TBD 4.1.8.1 Enumerated | 1633 |Fragmentation-Flag TBD 4.1.8.2 Enumerated | 1634 |IP-Option TBD 4.1.8.3 Grouped | 1635 |IP-Option-Type TBD 4.1.8.4 Enumerated | 1636 |IP-Option-Value TBD 4.1.8.5 OctetString | 1637 |TCP-Option TBD 4.1.8.6 Grouped | 1638 |TCP-Option-Type TBD 4.1.8.7 Enumerated | 1639 |TCP-Option-Value TBD 4.1.8.8 OctetString | 1640 |TCP-Flags TBD 4.1.8.9 Grouped | 1641 |TCP-Flag-Type TBD 4.1.8.10 Unsigned32 | 1642 |ICMP-Type TBD 4.1.8.11 Grouped | 1643 |ICMP-Type-Number TBD 4.1.8.12 Enumerated | 1644 |ICMP-Code TBD 4.1.8.13 Enumerated | 1645 |ETH-Option TBD 4.1.8.14 Grouped | 1646 |ETH-Proto-Type TBD 4.1.8.15 Grouped | 1647 |ETH-Ether-Type TBD 4.1.8.16 OctetString | 1648 |ETH-SAP TBD 4.1.8.17 OctetString | 1649 |VLAN-ID-Range TBD 4.1.8.18 Grouped | 1650 |S-VID-Start TBD 4.1.8.19 Unsigned32 | 1651 |S-VID-End TBD 4.1.8.20 Unsigned32 | 1652 |C-VID-Start TBD 4.1.8.21 Unsigned32 | 1653 |C-VID-End TBD 4.1.8.22 Unsigned32 | 1654 |User-Priority-Range TBD 4.1.8.23 Grouped | 1655 |Low-User-Priority TBD 4.1.8.24 Unsigned32 | 1656 |High-User-Priority TBD 4.1.8.25 Unsigned32 | 1657 |Time-Of-Day-Condition TBD 4.2.1 Grouped | 1658 |Time-Of-Day-Start TBD 4.2.2 Unsigned32 | 1659 |Time-Of-Day-End TBD 4.2.3 Unsigned32 | 1660 |Day-Of-Week-Mask TBD 4.2.4 Unsigned32 | 1661 |Day-Of-Month-Mask TBD 4.2.5 Unsigned32 | 1662 |Month-Of-Year-Mask TBD 4.2.6 Unsigned32 | 1663 |Absolute-Start-Time TBD 4.2.7 Time | 1664 |Absolute-Start-Fractional-Seconds TBD 4.2.8 Unsigned32 | 1665 |Absolute-End-Time TBD 4.2.9 Time | 1666 |Absolute-End-Fractional-Seconds TBD 4.2.10 Unsigned32 | 1667 |Timezone-Flag TBD 4.2.11 Enumerated | 1668 |Timezone-Offset TBD 4.2.12 Integer32 | 1669 |QoS-Action TBD 5.1 Grouped | 1670 |QoS-Profile-Id TBD 5.2 Unsigned32 | 1671 |QoS-Profile-Template TBD 5.3 Grouped | 1672 |QoS-Semantics TBD 5.4 Enumerated | 1673 |QoS-Parameters TBD 5.5 Grouped | 1674 |Excess-Treatment TBD 5.6 Grouped | 1675 |QoS-Capability TBD 6 Grouped | 1676 +--------------------------------------------------------------------+ 1678 10.2. QoS-Semantics IANA Registry 1680 IANA is also requested to allocate a new registry under 1681 Authentication, Authorization, and Accounting (AAA) Parameters for 1682 the QoS-Semantics AVP. The following values are allocated by this 1683 specification: 1685 (0): QoS-Desired 1686 (1): QoS-Available 1687 (2): QoS-Reserved 1688 (3): Minimum-QoS 1689 (4): QoS-Authorized 1691 The definition of new values is subject to the Specification Required 1692 policy [RFC5226]. 1694 10.3. Action 1696 IANA is also requested to allocate a new registry under 1697 Authentication, Authorization, and Accounting (AAA) Parameters for 1698 the QoS-Action AVP. The following values are allocated by this 1699 specification: 1701 0: drop 1702 1: shape 1703 2: mark 1705 The definition of new values is subject to the Specification Required 1706 policy [RFC5226]. 1708 11. Security Considerations 1710 This document describes the extension of Diameter for conveying 1711 Quality of Service information. The security considerations of the 1712 Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. 1713 Use of the AVPs defined in this document MUST take into consideration 1714 the security issues and requirements of the Diameter Base protocol. 1716 12. References 1718 12.1. Normative References 1720 [IEEE802.1D] 1721 IEEE, "IEEE Standard for Local and metropolitan area 1722 networks, Media Access Control (MAC) Bridges", 2004. 1724 [IEEE802.1Q] 1725 IEEE, "IEEE Standard for Local and metropolitan area 1726 networks, Virtual Bridged Local Area Networks", 2005. 1728 [IEEE802.1ad] 1729 IEEE, "IEEE Standard for Local and metropolitan area 1730 networks, Virtual Bridged Local Area Networks, Amendment 1731 4: Provider Bridges", 2005. 1733 [IEEE802.2] 1734 IEEE, "IEEE Standard for Information technology, 1735 Telecommunications and information exchange between 1736 systems, Local and metropolitan area networks, Specific 1737 requirements, Part 2: Logical Link Control", 1998. 1739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1740 Requirement Levels", BCP 14, RFC 2119, March 1997. 1742 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1743 "Definition of the Differentiated Services Field (DS 1744 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1745 December 1998. 1747 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1748 Values In the Internet Protocol and Related Headers", 1749 BCP 37, RFC 2780, March 2000. 1751 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1752 of Explicit Congestion Notification (ECN) to IP", 1753 RFC 3168, September 2001. 1755 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1756 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1758 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1759 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1760 May 2008. 1762 12.2. Informative References 1764 [I-D.ietf-dime-diameter-qos] 1765 Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 1766 and G. Zorn, "Diameter Quality of Service Application", 1767 draft-ietf-dime-diameter-qos-09 (work in progress), 1768 July 2009. 1770 [I-D.ietf-dime-qos-parameters] 1771 Korhonen, J., Tschofenig, H., and E. Davies, "Quality of 1772 Service Parameters for Usage with Diameter", 1773 draft-ietf-dime-qos-parameters-11 (work in progress), 1774 May 2009. 1776 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1777 and W. Weiss, "An Architecture for Differentiated 1778 Services", RFC 2475, December 1998. 1780 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1781 "Diameter Network Access Server Application", RFC 4005, 1782 August 2005. 1784 Authors' Addresses 1786 Jouni Korhonen 1787 Nokia Siemens Networks 1788 Linnoitustie 6 1789 Espoo 02600 1790 Finland 1792 Email: jouni.korhonen@nsn.com 1794 Hannes Tschofenig 1795 Nokia Siemens Networks 1796 Linnoitustie 6 1797 Espoo 02600 1798 Finland 1800 Phone: +358 (50) 4871445 1801 Email: Hannes.Tschofenig@gmx.net 1802 URI: http://www.tschofenig.priv.at 1803 Mayutan Arumaithurai 1804 University of Goettingen 1806 Email: mayutan.arumaithurai@gmail.com 1808 Mark Jones (editor) 1809 Bridgewater Systems 1810 303 Terry Fox Drive, Suite 500 1811 Ottawa, Ontario K2K 3J1 1812 Canada 1814 Phone: +1 613-591-6655 1815 Email: mark.jones@bridgewatersystems.com 1817 Avi Lior 1818 Bridgewater Systems 1819 303 Terry Fox Drive, Suite 500 1820 Ottawa, Ontario K2K 3J1 1821 Canada 1823 Phone: +1 613-591-6655 1824 Email: avi@bridgewatersystems.com