idnits 2.17.1 draft-ietf-dime-qos-attributes-14.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 (October 23, 2009) is 5296 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-12 -- 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: April 26, 2010 University of Goettingen 7 M. Jones, Ed. 8 A. Lior 9 Bridgewater Systems 10 October 23, 2009 12 Quality of Service Attributes for Diameter 13 draft-ietf-dime-qos-attributes-14.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 April 26, 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 defines a number of Diameter Quality of Service (QoS) 61 related attribute-value pairs (AVP) that can be used in existing and 62 future Diameter applications where permitted by the Augmented Backus- 63 Naur Form (ABNF) specification of the command. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Rule Sets and Rules . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 5 71 3.2. QoS-Rule AVP . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.3. QoS-Rule-Precedence AVP . . . . . . . . . . . . . . . . . 6 73 4. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 6 75 4.1.1. Classifier AVP . . . . . . . . . . . . . . . . . . . . 8 76 4.1.2. Classifier-ID AVP . . . . . . . . . . . . . . . . . . 9 77 4.1.3. Protocol AVP . . . . . . . . . . . . . . . . . . . . . 9 78 4.1.4. Direction AVP . . . . . . . . . . . . . . . . . . . . 9 79 4.1.5. From-Spec AVP . . . . . . . . . . . . . . . . . . . . 9 80 4.1.6. To-Spec AVP . . . . . . . . . . . . . . . . . . . . . 10 81 4.1.7. Source and Destination AVPs . . . . . . . . . . . . . 11 82 4.1.8. Header Option AVPs . . . . . . . . . . . . . . . . . . 15 83 4.2. Time Of Day AVPs . . . . . . . . . . . . . . . . . . . . . 22 84 4.2.1. Time-Of-Day-Condition AVP . . . . . . . . . . . . . . 22 85 4.2.2. Time-Of-Day-Start AVP . . . . . . . . . . . . . . . . 23 86 4.2.3. Time-Of-Day-End AVP . . . . . . . . . . . . . . . . . 23 87 4.2.4. Day-Of-Week-Mask AVP . . . . . . . . . . . . . . . . . 23 88 4.2.5. Day-Of-Month-Mask AVP . . . . . . . . . . . . . . . . 23 89 4.2.6. Month-Of-Year-Mask AVP . . . . . . . . . . . . . . . . 24 90 4.2.7. Absolute-Start-Time AVP . . . . . . . . . . . . . . . 24 91 4.2.8. Absolute-Start-Fractional-Seconds AVP . . . . . . . . 24 92 4.2.9. Absolute-End-Time AVP . . . . . . . . . . . . . . . . 24 93 4.2.10. Absolute-End-Fractional-Seconds AVP . . . . . . . . . 25 94 4.2.11. Timezone-Flag AVP . . . . . . . . . . . . . . . . . . 25 95 4.2.12. Timezone-Offset AVP . . . . . . . . . . . . . . . . . 25 97 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 5.1. QoS-Action AVP . . . . . . . . . . . . . . . . . . . . . . 25 99 5.2. QoS-Profile-Id AVP . . . . . . . . . . . . . . . . . . . . 26 100 5.3. QoS-Profile-Template AVP . . . . . . . . . . . . . . . . . 27 101 5.4. QoS-Semantics . . . . . . . . . . . . . . . . . . . . . . 27 102 5.5. QoS-Parameters AVP . . . . . . . . . . . . . . . . . . . . 28 103 5.6. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 29 104 6. QoS Capability Indication . . . . . . . . . . . . . . . . . . 29 105 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 106 7.1. Diameter EAP with QoS Information . . . . . . . . . . . . 30 107 7.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 31 108 7.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 32 109 7.4. Diameter Server Initiated Re-authorization of QoS . . . . 32 110 7.5. Diameter Credit Control with QoS Information . . . . . . . 33 111 7.6. Classifier Examples . . . . . . . . . . . . . . . . . . . 34 112 7.7. QoS Examples . . . . . . . . . . . . . . . . . . . . . . . 36 113 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 114 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 115 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 116 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 118 12.1. Normative References . . . . . . . . . . . . . . . . . . . 39 119 12.2. Informative References . . . . . . . . . . . . . . . . . . 40 120 Appendix A. MAC and EUI64 Address Mask Usage Considerations . . . 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. This includes the ability to match on 142 Ethernet specific attributes which was not possible with the QoS- 143 Filter-Rule AVP. Service differentiation may be based on Ethernet 144 priority bits, a single layer of VLAN-IDs or stacked VLAN-IDs, LLC 145 attributes, MAC addresses or any combination thereof. The header 146 fields used for Ethernet classification are defined in the IEEE802 147 series of specifications: [IEEE802.2], [IEEE802.1ad], [IEEE802.1Q] 148 and [IEEE802.1D]. Additionally, time-based conditions can be 149 expressed based on the functionality offered by the attributes in 150 Section 4.2. 152 The action part of a rule contains information for handling conflict 153 resolution, such as a priority value for each individual rule within 154 a rule set, and further description regarding QoS related actions. 156 The QoS policy rules are defined as Diameter encoded Attribute Value 157 Pairs (AVPs) described using a modified version of the Augmented 158 Backus-Naur Form (ABNF), see [RFC3588]. The AVP datatypes are also 159 taken from [RFC3588]. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 3. Rule Sets and Rules 169 As mentioned in the introduction the top-level element is the QoS- 170 Resources AVP that encapsulates one or more QoS-Rule AVPs. 172 3.1. QoS-Resources AVP 174 The QoS-Resources AVP (AVP Code TBD) is of type Grouped and contains 175 a list of QoS policy rules. 177 QoS-Resources ::= < AVP Header: XXX > 178 1*{ QoS-Rule } 179 * [ AVP ] 181 3.2. QoS-Rule AVP 183 The QoS-Rule AVP (AVP Code TBD) is of type Grouped and defines a 184 specific condition and action combination. 186 QoS-Rule ::= < AVP Header: XXX > 187 [ QoS-Rule-Precedence ] 189 ; Condition part of a Rule 190 ; ------------------------ 192 [ Classifier ] 193 * [ Time-Of-Day-Condition ] 195 ; Action and Meta-Data 196 ; -------------------- 198 [ QoS-Action ] 200 ; Info about QoS related Actions 201 ; ------------------------------ 203 [ QoS-Semantics ] 204 [ QoS-Profile-Template ] 205 [ QoS-Parameters ] 206 [ Excess-Treatment ] 208 ; Extension Point 209 ; --------------- 210 * [ AVP ] 212 If the QoS-Profile-Template AVP is not included in the Qos-Rule AVP 213 then the default setting is assumed, namely a setting of the 214 Vendor-Id AVP to 0 (for IETF) and the QoS-Profile-Id AVP to zero (0) 215 (for the profile defined in [I-D.ietf-dime-qos-parameters]). Note 216 that the content of the QoS-Parameters are defined in the respective 217 specification defining the QoS parameters. When the Vendor-Id AVP is 218 set to 0 (for IETF) and the QoS-Profile-Id AVP is set to zero (0) 219 then the AVPs included in the QoS-Parameters AVP are the AVPs defined 220 in [I-D.ietf-dime-qos-parameters]. 222 3.3. QoS-Rule-Precedence AVP 224 The QoS-Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and 225 specifies the execution order of the rules expressed in the QoS- 226 Resources AVP. The lower the numerical value of QoS-Rule-Precedence 227 AVP, the higher the rule precedence. Rules with equal precedence MAY 228 be executed in parallel if supported by the Resource Management 229 Function. If the QoS-Rule-Precedence AVP is absent from the QoS-Rule 230 AVP, the rules SHOULD be executed in the order in which they appear 231 in the QoS-Resources AVP. 233 4. Conditions 235 This section describes the condition part of a rule. Two condition 236 types are introduced by this document: packet classification 237 conditions represented by the Classifier AVP and time of day 238 conditions represented by the Time-Of-Day-Condition AVP. 240 If more than one instance of the Time-Of-Day-Condition AVP is present 241 in the QoS-Rule AVP, the current time at QoS rule evaluation MUST be 242 within at least one of the time windows specified in one of the Time- 243 Of-Day-Condition AVPs. 245 When the Time-Of-Day-Condition AVP and Classifier AVP are present in 246 the same QoS-Rule AVP, both the time of day and packet classification 247 conditions MUST match for the QoS specification action to be applied. 249 4.1. Traffic Classifiers 251 Classifiers are used in many applications to specify how to select a 252 subset of data packets for subsequent treatment as indicated in the 253 action part of a rule. For example in a QoS application, if a packet 254 matches a classifier then that packet will be treated in accordance 255 with a QoS specification associated with that classifier. Figure 1 256 shows a typical deployment. 258 +-----------+ 259 +-----------+| 260 +--------+ +-------------+ +------------+|| 261 | | IN | | | ||| 262 | +--------->| +------------->| ||| 263 |Managed | | Classifying | | Unmanaged ||| 264 |Terminal| OUT | Entity | | Terminal ||| 265 | |<---------+ |<-------------+ ||+ 266 | | | | | |+ 267 +--------+ +-------------+ +------------+ 268 ^ 269 | Classifiers 270 | 271 +------+------+ 272 | | 273 | AAA | 274 | | 275 +-------------+ 277 Figure 1: Example of a Classifier Architecture 279 The managed terminal, the terminal for which the classifiers are 280 being specified is located on the left of the Classifying Entity. 281 The unmanaged terminals, the terminals that receive packets from the 282 Managed terminal or send packets to the managed terminal are located 283 to the right side of the Classifying Entity. 285 The Classifying Entity is responsible for classifying packets that 286 are incoming (IN) from the Managed Terminal or packets outgoing (OUT) 287 to the Managed Terminal. 289 A Classifier consists of a group of attributes that specify how to 290 match a packet. Each set of attributes expresses values about 291 aspects of the packet - typically the packet header. Different 292 protocols therefore would use different attributes. 294 In general a Classifier consists of the following: 296 Identifier: 298 The identifier uniquely identifies this classifier and may be used 299 to reference the classifier from another structure. 301 From: 303 Specifies the rule for matching the protocol specific source 304 address(es) part of the packet. 306 To: 308 Specifies the rule for matching the protocol specific destination 309 address(es) part of the packet. 311 Protocol: 313 Specifies the matching protocol of the packet. 315 Direction: 317 Specifies whether the classifier is to apply to packets flowing 318 from the Managed Terminal (IN) or to packets flowing to the 319 Managed Terminal (OUT), or packets flowing in both direction. 321 Options: 323 Attributes or properties associated with each protocol or layer, 324 or various values specific to the header of the protocol or layer. 325 Options allow matching on those values. 327 Each protocol type will have a specific set of attributes that can be 328 used to specify a classifier for that protocol. These attributes 329 will be grouped under a grouped AVP called a Classifier AVP. 331 4.1.1. Classifier AVP 333 The Classifier AVP (AVP Code TBD) is a grouped AVP that consists of a 334 set of attributes that specify how to match a packet. 336 Classifier ::= < AVP Header: XXX > 337 { Classifier-ID } 338 [ Protocol ] 339 [ Direction ] 340 * [ From-Spec ] 341 * [ To-Spec ] 342 * [ Diffserv-Code-Point ] 343 [ Fragmentation-Flag ] 344 * [ IP-Option ] 345 * [ TCP-Option ] 346 [ TCP-Flags ] 347 * [ ICMP-Type ] 348 * [ ETH-Option ] 349 * [ AVP ] 351 4.1.2. Classifier-ID AVP 353 The Classifier-ID AVP (AVP Code TBD) is of type OctetString and 354 uniquely identifies the classifier. Each application will define the 355 uniqueness scope of this identifier, e.g. unique per terminal or 356 globally unique. Exactly one Classifier-ID AVP MUST be contained 357 within a Classifier AVP. 359 4.1.3. Protocol AVP 361 The Protocol AVP (AVP Code TBD) is of type Enumerated and specifies 362 the protocol being matched. The attributes included in the 363 Classifier AVP MUST be consistent with the value of the Protocol AVP. 364 Exactly zero or one Protocol AVP may be contained within a Classifier 365 AVP. If the Protocol AVP is omitted from the Classifier, then 366 comparison of the protocol of the packet is irrelevant. The values 367 for this AVP are managed by IANA under the Protocol Numbers registry 368 as defined in [RFC2780]. 370 4.1.4. Direction AVP 372 The Direction AVP (AVP Code TBD) is of type Enumerated and specifies 373 in which direction to apply the Classifier. The values of the 374 enumeration are: "IN","OUT","BOTH". In the "IN" and "BOTH" 375 directions, the From-Spec refers to the address of the Managed 376 Terminal and the To-Spec refers to the unmanaged terminal. In the 377 "OUT" direction, the From-Spec refers to the Unmanaged Terminal 378 whereas the To-Spec refers to the Managed Terminal. If the Direction 379 AVP is omitted, the Classifier matches packets flowing in both 380 directions. 382 Value | Name and Semantic 383 ------+-------------------------------------------------- 384 0 | IN - The classifier applies to flows from the 385 | Managed Terminal. 386 1 | OUT - The classifier applies to flows to the 387 | Managed Terminal. 388 2 | BOTH - The classifier applies to flows both to 389 | and from the Managed Terminal. 391 4.1.5. From-Spec AVP 393 The From-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the 394 Source Specification used to match the packet. Zero or more of these 395 AVPs may appear in the Classifier. If this AVP is absent from the 396 Classifier then all packets are matched regardless of the source 397 address. If more than one instance of this AVP appears in the 398 Classifier then the source of the packet can match any From-Spec AVP. 399 The contents of this AVP are protocol specific. 401 If one instance (or multiple instances) of the IP address AVP (IP- 402 Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) 403 appear in the From-Spec AVP then the source IP address of the packet 404 MUST match one of the addresses represented by these AVPs. 406 If more that one instance of the layer 2 address AVPs (MAC-Address, 407 MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the 408 From-Spec then the the source layer 2 address of the packet MUST 409 match one of the addresses represented in these AVPs. 411 If more that one instance of the port AVPs (Port, Port-Range) appears 412 in the From-Spec AVP then the source port number MUST match one of 413 the port numbers represented in these AVPs. 415 If the IP address, MAC address and port AVPs appear in the same From- 416 Spec AVP then the source packet MUST match all the specifications, 417 i.e. match the IP address AND MAC address AND port number. 419 From-Spec ::= < AVP Header: XXX > 420 * [ IP-Address ] 421 * [ IP-Address-Range ] 422 * [ IP-Address-Mask ] 423 * [ MAC-Address ] 424 * [ MAC-Address-Mask] 425 * [ EUI64-Address ] 426 * [ EUI64-Address-Mask] 427 * [ Port ] 428 * [ Port-Range ] 429 [ Negated ] 430 [ Use-Assigned-Address ] 431 * [ AVP ] 433 4.1.6. To-Spec AVP 435 The To-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the 436 Destination Specification used to match the packet. Zero or more of 437 these AVPs may appear in the Classifier. If this AVP is absent from 438 the Classifier then all packets are matched regardless of the 439 destination address. If more than one instance of this AVP appears 440 in the Classifier then the destination of the packet can match any 441 To-Spec AVP. The contents of this AVP are protocol specific. 443 If one instance (or multiple instances) of the IP address AVP (IP- 444 Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) 445 appear in the To-Spec AVP then the destination IP address of the 446 packet MUST match one of the addresses represented by these AVPs. 448 If more that one instance of the layer 2 address AVPs (MAC-Address, 449 MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the 450 To-Spec then the the destination layer 2 address of the packet MUST 451 match one of the addresses represented in these AVPs. 453 If more that one instance of the port AVPs (Port, Port-Range) appears 454 in the To-Spec AVP then the destination port number MUST match one of 455 the port numbers represented in these AVPs. 457 If the IP address, MAC address and port AVPs appear in the same To- 458 Spec AVP then the destination packet MUST match all the 459 specifications, i.e. match the IP address AND MAC address AND port 460 number. 462 To-Spec ::= < AVP Header: XXX > 463 * [ IP-Address ] 464 * [ IP-Address-Range ] 465 * [ IP-Address-Mask ] 466 * [ MAC-Address ] 467 * [ MAC-Address-Mask] 468 * [ EUI64-Address ] 469 * [ EUI64-Address-Mask] 470 * [ Port ] 471 * [ Port-Range ] 472 [ Negated ] 473 [ Use-Assigned-Address ] 474 * [ AVP ] 476 4.1.7. Source and Destination AVPs 478 For packet classification the contents of the From-Spec and To-Spec 479 can contain the AVPs listed in the subsections below. 481 4.1.7.1. Negated AVP 483 The Negated AVP (AVP Code TBD) of type Enumerated containing the 484 values of True or False. Exactly zero or one of these AVPs may 485 appear in the From-Spec or To-Spec AVP. 487 When set to True the meaning of the match is inverted. Addresses 488 other than those in the To-Spec and From-Spec are to be matched 489 instead. When set to False, or when the AVP is not included then the 490 address specified To-Spec and From-Spec AVP are to be matched. 492 Note that the negation does not impact the port comparisons. 494 Value | Name 495 ------+-------- 496 0 | False 497 1 | True 499 4.1.7.2. IP-Address AVP 501 The IP-Address AVP (AVP Code TBD) is of type Address and specifies a 502 single IP address (IPv4 or IPv6) address to match. 504 4.1.7.3. IP-Address-Range AVP 506 The IP-Address-Range AVP (AVP Code TBD) is of type Grouped and 507 specifies an inclusive IP address range. 509 IP-Address-Range ::= < AVP Header: XXX > 510 [ IP-Address-Start ] 511 [ IP-Address-End ] 512 * [ AVP ] 514 If the IP-Address-Start AVP is not included then the address range 515 starts from the first valid IP address up to and including the 516 specified IP-Address-End address. 518 If the IP-Address-End AVP is not included then the address range 519 starts at the address specified by the IP-Address-Start AVP and 520 includes all the remaining valid IP addresses. 522 For the IP-Address-Range AVP to be valid, the IP-Address-Start AVP 523 MUST contain a value that is less than that of the IP-Address-End 524 AVP. 526 4.1.7.4. IP-Address-Start AVP 528 The IP-Address-Start AVP (AVP Code TBD) is of type Address and 529 specifies the first IP address (IPv4 or IPv6) address of an IP 530 address range. 532 4.1.7.5. IP-Address-End AVP 534 The IP-Address-End AVP (AVP Code TBD) is of type Address and 535 specifies the last IP address (IPv4 or IPv6) address of an address 536 range. 538 4.1.7.6. IP-Address-Mask AVP 540 The IP-Address-Mask AVP (AVP Code TBD) is of type Grouped and 541 specifies an IP address range using a base IP address and the bit- 542 width of the mask. For example, a range expressed as 192.0.2.0/24 543 will match all IP addresses from 192.0.2.0 up to and including 544 192.0.2.255. The bit-width MUST be valid for the type of IP address. 546 IP-Address-Mask ::= < AVP Header: XXX > 547 { IP-Address } 548 { IP-Bit-Mask-Width } 549 * [ AVP ] 551 4.1.7.7. IP-Mask-Bit-Mask-Width AVP 553 The IP-Bit-Mask-Width AVP (AVP Code TBD) is of type Unsigned32. The 554 value specifies the width of an IP address bit-mask. 556 4.1.7.8. MAC-Address AVP 558 The MAC-Address AVP (AVP Code TBD) is of type OctetString and 559 specifies a single layer 2 address in MAC-48 format. The value is a 560 6 octets encoding of the address as it would appear in the frame 561 header. 563 4.1.7.9. MAC-Address-Mask AVP 565 The MAC-Address-Mask AVP (AVP Code TBD) is of type Grouped and 566 specifies a set of MAC addresses using a bit mask to indicate the 567 bits of the MAC addresses which must fit to the specified MAC address 568 attribute. For example, a MAC-Address-Mask with the MAC-Address as 569 00-10-A4-23-00-00 and with a MAC-Address-Mask-Pattern of FF-FF-FF-FF- 570 00-00 will match all MAC addresses from 00-10-A4-23-00-00 up to and 571 including 00-10-A4-23-FF-FF. 573 Appendix A describes the considerations that should be given to the 574 use of MAC address masks in constructing Classifiers. 576 MAC-Address-Mask ::= < AVP Header: XXX > 577 { MAC-Address } 578 { MAC-Address-Mask-Pattern } 579 * [ AVP ] 581 4.1.7.10. MAC-Address-Mask-Pattern AVP 583 The MAC-Address-Mask-Pattern AVP (AVP Code TBD) is of type 584 OctetString. The value is a 6 octets specifying the bit positions of 585 a MAC address, that are taken for matching. 587 4.1.7.11. EUI64-Address AVP 589 The EUI64-Address AVP (AVP Code TBD) is of type OctetString and 590 specifies a single layer 2 address in EUI-64 format. The value is a 591 8 octets encoding of the address as it would appear in the frame 592 header. 594 4.1.7.12. EUI64-Address-Mask AVP 596 The EUI64-Address-Mask AVP (AVP Code TBD) is of type Grouped and 597 specifies a set of EUI64 addresses using a bit mask to indicate the 598 bits of the EUI64 addresses which must fit to the specified EUI64 599 address attribute. For example, a EUI64-Address-Mask with the EUI64- 600 Address as 00-10-A4-FF-FE-23-00-00 and with a EUI64-Address-Mask- 601 Pattern of FF-FF-FF-FF-FF-FF-00-00 will match all EUI64 addresses 602 from 00-10-A4-FF-FE-23-00-00 up to and including 00-10-A4-FF-FE-23- 603 FF-FF. 605 Appendix A describes the considerations that should be given to the 606 use of EUI64 address masks in constructing Classifiers. 608 EUI64-Address-Mask ::= < AVP Header: XXX > 609 { EUI64-Address } 610 { EUI64-Address-Mask-Pattern } 611 * [ AVP ] 613 4.1.7.13. EUI64-Address-Mask-Pattern AVP 615 The EUI64-Address-Mask-Pattern AVP (AVP Code TBD) is of type 616 OctetString. The value is a 8 octets specifying the bit positions of 617 a EUI64 address, that are taken for matching. 619 4.1.7.14. Port AVP 621 The Port AVP (AVP Code TBD) is of type Integer32 in the range of 0 to 622 65535 and specifies port numbers to match. The type of port is 623 indicated by the value of the Protocol AVP, i.e. if Procotol AVP 624 value is 6 (TCP) then the Port AVP represents a TCP port. 626 4.1.7.15. Port-Range AVP 628 The Port-Range AVP (AVP Code TBD) is of type Grouped and specifies an 629 inclusive range of ports. The type of the ports is indicated by the 630 value of the Protocol AVP, i.e. if Procotol AVP value is 6 (TCP) then 631 the Port-Range AVP represents an inclusive range of TCP ports. 633 Port-Range ::= < AVP Header: XXX > 634 [ Port-Start ] 635 [ Port-End ] 636 * [ AVP ] 638 If the Port-Start AVP is omitted then port 0 is assumed. If the 639 Port-End AVP is omitted then port 65535 is assumed. 641 4.1.7.16. Port-Start AVP 643 The Port-Start AVP (AVP Code TBD) is of type Integer32 and specifies 644 the first port number of an IP port range. 646 4.1.7.17. Port-End AVP 648 The Port-End AVP (AVP Code TBD) is of type Integer32 and specifies 649 the last port number of an IP port range. 651 4.1.7.18. Use-Assigned-Address AVP 653 In some scenarios, the AAA does not know the IP address assigned to 654 the Managed Terminal at the time that the Classifier is sent to the 655 Classifying Entity. The Use-Assigned-Address AVP (AVP Code TBD) is 656 of type Enumerated containing the values of True or False. When 657 present and set to True, it represents the IP address assigned to the 658 Managed Terminal. 660 Value | Name 661 ------+-------- 662 0 | False 663 1 | True 665 4.1.8. Header Option AVPs 667 The Classifier AVP may contain one or more of the following AVPs to 668 match on the various possible IP, TCP or ICMP header options. 670 4.1.8.1. Diffserv-Code-Point AVP 672 The Diffserv-Code-Point AVP (AVP Code TBD) is of type Enumerated and 673 specifies the Differentiated Services Field Codepoints to match in 674 the IP header. The values are managed by IANA under the 675 Differentiated Services Field Codepoints registry as defined in 676 [RFC2474]. 678 4.1.8.2. Fragmentation-Flag AVP 680 The Fragmentation-Flag AVP (AVP Code TBD) is of type Enumerated and 681 specifies the packet fragmentation flags to match in the IP header. 683 Value | Name and Semantic 684 ------+------------------------------------------------------------ 685 0 | Don't Fragment (DF) 686 1 | More Fragments (MF) 688 4.1.8.3. IP-Option AVP 690 The IP-Option AVP (AVP Code TBD) is of type Grouped and specifies an 691 IP header option that must be matched. 693 IP-Option ::= < AVP Header: XXX > 694 { IP-Option-Type } 695 * [ IP-Option-Value ] 696 [ Negated ] 697 * [ AVP ] 699 If one or more IP-Option-Value AVPs are present, one of the values 700 MUST match the value in the IP header option. If the IP-Option-Value 701 AVP is absent, the option type MUST be present in the IP header but 702 the value is wild carded. 704 The Negated AVP is used in conjunction with the IP-Option-Value AVPs 705 to specify IP header options which do not match specific values. The 706 Negated AVP is used without the IP-Option-Value AVP to specify IP 707 headers which do not contain the option type. 709 4.1.8.4. IP-Option-Type AVP 711 The IP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the 712 values are managed by IANA under the IP Option Numbers registry as 713 defined in [RFC2780]. 715 4.1.8.5. IP-Option-Value AVP 717 The IP-Option-Value AVP (AVP Code TBD) is of type OctetString and 718 contains the option value that must be matched. 720 4.1.8.6. TCP-Option AVP 722 The TCP-Option AVP (AVP Code TBD) is of type Grouped and specifies a 723 TCP header option that must be matched. 725 TCP-Option ::= < AVP Header: XXX > 726 { TCP-Option-Type } 727 * [ TCP-Option-Value ] 728 [ Negated ] 729 * [ AVP ] 731 If one or more TCP-Option-Value AVPs are present, one of the values 732 MUST match the value in the TCP header option. If the TCP-Option- 733 Value AVP is absent, the option type MUST be present in the TCP 734 header but the value is wild carded. 736 The Negated AVP is used in conjunction which the TCP-Option-Value 737 AVPs to specify TCP header options which do not match specific 738 values. The Negated AVP is used without the TCP-Option-Value AVP to 739 specify TCP headers which do not contain the option type. 741 4.1.8.7. TCP-Option-Type AVP 743 The TCP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the 744 values are managed by IANA under the TCP Option Numbers registry as 745 defined in [RFC2780]. 747 4.1.8.8. TCP-Option-Value AVP 749 The TCP-Option-Value AVP (AVP Code TBD) is of type OctetString and 750 contains the option value that must be matched. 752 4.1.8.9. TCP-Flags AVP 754 The TCP-Flags AVP (AVP Code TBD) is of type Grouped and specifies a 755 set of TCP control flags that must be matched. 757 TCP-Flags ::= < AVP Header: XXX > 758 { TCP-Flag-Type } 759 [ Negated ] 760 * [ AVP ] 762 If the Negated AVP is not present or present but set to False, the 763 TCP-Flag-Type AVP specifies which flags MUST be set. If the Negated 764 AVP is set to True, the TCP-Flag-Type AVP specifies which flags MUST 765 be cleared. 767 4.1.8.10. TCP-Flag-Type AVP 769 The TCP-Flag-Type AVP (AVP Code TBD) is of type Unsigned32 and 770 specifies the TCP control flag types that must be matched. The first 771 16 bits match the TCP header format defined in [RFC3168] and the 772 subsequent 16 bits are unused. Within the first 16 bits, bits 0 to 3 773 are unused and bits 4 to 15 are managed by IANA under the TCP Header 774 Flag registry as defined in [RFC3168]. 776 4.1.8.11. ICMP-Type 778 The ICMP-Type AVP (AVP Code TBD) is of type Grouped and specifies a 779 ICMP message type that must be matched. 781 ICMP-Type ::= < AVP Header: XXX > 782 { ICMP-Type-Number } 783 * [ ICMP-Code ] 784 [ Negated ] 785 * [ AVP ] 787 If the ICMP-Code AVP is present, the value MUST match that in the 788 ICMP header. If the ICMP-Code AVP is absent, the ICMP type MUST be 789 present in the ICMP header but the code is wild carded. 791 The Negated AVP is used in conjunction with the ICMP-Code AVPs to 792 specify ICMP codes that do not match specific values. The Negated 793 AVP is used without the ICMP-Code AVP to specify ICMP headers which 794 do not contain the ICMP type. As such, the Negated AVP feature 795 applies to ICMP-Code AVP if the ICMP-Code AVP is present. If the 796 ICMP-Code AVP is absent, the Negated AVP feature applies to the ICMP- 797 Type-Number. 799 4.1.8.12. ICMP-Type-Number AVP 801 The ICMP-Type-Number AVP (AVP Code TBD) is of type Enumerated and the 802 values are managed by IANA under the ICMP Type Numbers registry as 803 defined in [RFC2780]. 805 4.1.8.13. ICMP-Code AVP 807 The ICMP-Code AVP (AVP Code TBD) is of type Enumerated and the values 808 are managed by IANA under the ICMP Type Numbers registry as defined 809 in [RFC2780]. 811 4.1.8.14. ETH-Option AVP 813 The ETH-Option AVP (AVP Code TBD) is of type Grouped and specifies 814 Ethernet specific attributes. 816 ETH-Option ::= < AVP Header: XXX > 817 { ETH-Proto-Type } 818 * [ VLAN-ID-Range ] 819 * [ User-Priority-Range ] 820 * [ AVP ] 822 4.1.8.15. ETH-Proto-Type AVP 824 The Eth-Proto-Type AVP (AVP Code TBD) is of type Grouped and 825 specifies the encapsulated protocol type. ETH-Ether-Type and ETH-SAP 826 are mutually exclusive. 828 ETH-Proto-Type ::= < AVP Header: XXX > 829 * [ ETH-Ether-Type ] 830 * [ ETH-SAP ] 831 * [ AVP ] 833 4.1.8.16. ETH-Ether-Type AVP 835 The ETH-Ether-Type AVP (AVP Code TBD) is of type OctetString. The 836 value is a double octet that contains the value of the Ethertype 837 field in the packet to match. This AVP MAY be present in the case of 838 DIX or if SNAP is present at 802.2 but the ETH-SAP AVP MUST NOT be 839 present in this case. 841 4.1.8.17. ETH-SAP AVP 843 The ETH-SAP AVP (AVP Code TBD) is of type OctetString. The value is 844 a double octet representing the 802.2 SAP as specified in 845 [IEEE802.2]. The first octet contains the DSAP and the second the 846 SSAP. 848 4.1.8.18. VLAN-ID-Range AVP 850 The VLAN-ID-Range AVP (AVP Code TBD) is of type Grouped and specifies 851 the VLAN range to match. VLAN identities are either specified by a 852 single VLAN-ID according to [IEEE802.1Q] or by a combination of 853 Customer and Service VLAN-IDs according to [IEEE802.1ad]. 855 The single VLAN-ID is represented by the C-VID-Start and C-VID-End 856 AVPs and the S-VID-Start and S-VID-End AVPs SHALL be ommitted in this 857 case. If the VLAN-ID-Range AVP is omitted from the Classifier, then 858 comparison of the VLAN identity of the packet is irrelevant. 860 VLAN-ID-Range ::= < AVP Header: XXX > 861 [ S-VID-Start ] 862 [ S-VID-End ] 863 [ C-VID-Start ] 864 [ C-VID-End ] 865 * [ AVP ] 867 The following is the list of possible combinations of the S-VID-Start 868 and S-VID-End AVPs and their inference: 870 o If S-VID-Start AVP is present but the S-VID-End AVP is absent, the 871 S-VID-Start AVP value MUST equal the value of the IEEE 802.1ad 872 S-VID bits specified in [IEEE802.1ad] for a successful match. 873 o If S-VID-Start AVP is absent but the S-VID-End AVP is present, the 874 S-VID-End AVP value MUST equal the value of the IEEE 802.1ad S-VID 875 bits for a successful match. 876 o If both S-VID-Start and S-VID-End AVPs are present and their 877 values are equal, the S-VID-Start AVP value MUST equal the value 878 of the IEEE 802.1ad S-VID bits for a successful match. 879 o If both S-VID-Start and S-VID-End AVPs are present and the value 880 of S-VID-End AVP is greater than the value of the S-VID-Start AVP, 881 the value of the IEEE 802.1ad S-VID bits MUST be greater than or 882 equal to the S-VID- Start AVP value and less than or equal to the 883 S-VID-End AVP value for a successful match. If the S-VID-Start 884 and S-VID-End AVPs are specified, then Ethernet packets without 885 IEEE 802.1ad encapsulation MUST NOT match this Classifier. 886 o If the S-VID-Start and S-VID-End AVPs are omitted, then existence 887 of IEEE802.1ad encapsulation or comparison of the IEEE 802.1ad 888 S-VID bits is irrelevant for this Classifier. 890 The following is the list of possible combinations of the C-VID-Start 891 and C-VID-End AVPs and their inference: 893 o If C-VID-Start AVP is present but the C-VID-End AVP is absent, the 894 C-VID-Start AVP value MUST equal the value of the IEEE 802.1ad 895 C-VID bits specified in [IEEE802.1ad] or the IEEE 802.1Q VLAN-ID 896 bits specified in [IEEE802.1Q] for a successful match. 897 o If C-VID-Start AVP is absent but the C-VID-End AVP is present, the 898 C-VID-End AVP value MUST equal the value of the IEEE 802.1ad C-VID 899 bits or the IEEE 802.1Q VLAN-ID bits for a successful match. 900 o If both C-VID-Start and C-VID-End AVPs are present and their 901 values are equal, the C-VID-Start AVP value MUST equal the value 902 of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits for 903 a successful match. 904 o If both C-VID-Start and C-VID-End AVPs are present and the value 905 of C-VID-End AVP is greater than the value of the C-VID-Start AVP, 906 the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q 907 VLAN-ID bits MUST be greater than or equal to the C-VID-Start AVP 908 value and less than or equal to the C-VID-End AVP value for a 909 successful match. If the C-VID-Start and C-VID-End AVPs are 910 specified, then Ethernet packets without IEEE 802.1ad or IEEE 911 802.1Q encapsulation MUST NOT match this Classifier. 912 o If the C-VID-Start and C-VID-End AVPs are omitted, the comparison 913 of the IEEE 802.1ad C-VID bits or IEEE 802.1Q VLAN-ID bits for 914 this Classifier is irrelevant. 916 4.1.8.19. S-VID-Start AVP 918 The S-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 S-VID VLAN-IDs to be matched. 922 4.1.8.20. S-VID-End AVP 924 The S-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 S-VID VLAN-IDs to be matched. 928 4.1.8.21. C-VID-Start AVP 930 The C-VID-Start AVP (AVP Code TBD) is of type Unsigned32. The value 931 MUST be in the range from 0 to 4095. The value of this AVP specifies 932 the start value of the range of C-VID VLAN-IDs to be matched. 934 4.1.8.22. C-VID-End AVP 936 The C-VID-End AVP (AVP Code TBD) is of type Unsigned32. The value 937 MUST be in the range from 0 to 4095. The value of this AVP specifies 938 the end value of the range of C-VID VLAN-IDs to be matched. 940 4.1.8.23. User-Priority-Range AVP 942 The User-Priority-Range AVP (AVP Code TBD) is of type Grouped and 943 specifies an inclusive range to match the user_priority parameter 944 specified in [IEEE802.1D]. An Ethernet packet containing the 945 user_priority parameter matches this Classifier if the value is 946 greater than or equal to Low-User-Priority and less than or equal to 947 High-User-Priority. If this AVP is omitted, then comparison of the 948 IEEE 802.1D user_priority parameter for this Classifier is 949 irrelevant. 951 User-Priority-Range ::= < AVP Header: XXX > 952 * [ Low-User-Priority ] 953 * [ High-User-Priority ] 954 * [ AVP ] 956 4.1.8.24. Low-User-Priority AVP 958 The Low-User-Priority AVP (AVP Code TBD) is of type Unsigned32. The 959 value MUST be in the range from 0 to 7. 961 4.1.8.25. High-User-Priority AVP 963 The High-User-Priority AVP (AVP Code TBD) is of type Unsigned32. The 964 value MUST be in the range from 0 to 7. 966 4.2. Time Of Day AVPs 968 In many QoS applications, the QoS specification applied to the 969 traffic flow is conditional upon the time of day when the flow was 970 observed. The following sections define AVPs that can be used to 971 express one or more time windows which determine when a QoS 972 specification is applicable to a traffic flow. 974 4.2.1. Time-Of-Day-Condition AVP 976 The Time-Of-Day-Condition AVP (AVP Code TBD) is of type Grouped and 977 specifies one or more time windows. 979 Time-Of-Day-Condition ::= < AVP Header: XXX > 980 [ Time-Of-Day-Start ] 981 [ Time-Of-Day-End ] 982 [ Day-Of-Week-Mask ] 983 [ Day-Of-Month-Mask ] 984 [ Month-Of-Year-Mask ] 985 [ Absolute-Start-Time ] 986 [ Absolute-End-Time ] 987 [ Timezone-Flag ] 988 * [ AVP ] 990 For example, a time window for 9am to 5pm (local time) from Monday to 991 Friday would be expressed as: 993 Time-Of-Day-Condition = { 994 Time-Of-Day-Start = 32400; 995 Time-Of-Day-End = 61200; 996 Day-Of-Week-Mask = 997 ( MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY ); 998 Timezone-Flag = LOCAL; 999 } 1001 4.2.2. Time-Of-Day-Start AVP 1003 The Time-Of-Day-Start AVP (AVP Code TBD) is of type Unsigned32. The 1004 value MUST be in the range from 0 to 86400. The value of this AVP 1005 specifies the start of an inclusive time window expressed as the 1006 offset in seconds from midnight. If this AVP is absent from the 1007 Time-Of-Day-Condition AVP, the time window starts at midnight. 1009 4.2.3. Time-Of-Day-End AVP 1011 The Time-Of-Day-End AVP (AVP Code TBD) is of type Unsigned32. The 1012 value MUST be in the range from 1 to 86400. The value of this AVP 1013 specifies the end of an inclusive time window expressed as the offset 1014 in seconds from midnight. If this AVP is absent from the Time-Of- 1015 Day-Condition AVP, the time window ends one second before midnight. 1017 4.2.4. Day-Of-Week-Mask AVP 1019 The Day-Of-Week-Mask AVP (AVP Code TBD) is of type Unsigned32. The 1020 value is a bitmask which specifies the day of the week for the time 1021 window to match. This document specifies the following bits: 1023 Bit | Name 1024 ------+------------ 1025 0 | SUNDAY 1026 1 | MONDAY 1027 2 | TUESDAY 1028 3 | WEDNESDAY 1029 4 | THURSDAY 1030 5 | FRIDAY 1031 6 | SATURDAY 1033 The bit MUST be set for the time window to match on the corresponding 1034 day of the week. Bit 0 is the least significant bit and unused bits 1035 MUST be cleared. If this AVP is absent from the Time-Of-Day- 1036 Condition AVP, the time windows match on all days of the week. 1038 4.2.5. Day-Of-Month-Mask AVP 1040 The Day-Of-Month AVP (AVP Code TBD) is of type Unsigned32. The value 1041 MUST be in the range from 0 to 2147483647. The value is a bitmask 1042 which specifies the days of the month where bit 0 represents the 1043 first day of the month through to bit 30 which represents the last 1044 day of the month. The bit MUST be set for the time window to match 1045 on the corresponding day of the month. Bit 0 is the least 1046 significant bit and unused bits MUST be cleared. If this AVP is 1047 absent from the Time-Of-Day-Condition AVP, the time windows match on 1048 all days of the month. 1050 4.2.6. Month-Of-Year-Mask AVP 1052 The Month-Of-Year-Mask AVP (AVP Code TBD) is of type Unsigned32. The 1053 value is a bitmask which specifies the months of the year for the 1054 time window to match. This document specifies the following bits: 1056 Bit | Name 1057 ------+----------- 1058 0 | JANUARY 1059 1 | FEBRUARY 1060 2 | MARCH 1061 3 | APRIL 1062 4 | MAY 1063 5 | JUNE 1064 6 | JULY 1065 7 | AUGUST 1066 8 | SEPTEMBER 1067 9 | OCTOBER 1068 10 | NOVEMBER 1069 11 | DECEMBER 1071 The bit MUST be set for the time window to match on the corresponding 1072 month of the year. Bit 0 is the least significant bit and unused 1073 bits MUST be cleared. If this AVP is absent from the Time-Of-Day- 1074 Condition AVP, the time windows match during all months of the year. 1076 4.2.7. Absolute-Start-Time AVP 1078 The Absolute-Start-Time AVP (AVP Code TBD) is of type Time. The 1079 value of this AVP specifies the time in seconds since January 1, 1080 1900, 00:00 UTC when the time window starts. If this AVP is absent 1081 from the Time-Of-Day-Condition AVP, the time window starts on January 1082 1, 1900, 00:00 UTC. 1084 4.2.8. Absolute-Start-Fractional-Seconds AVP 1086 The Absolute-Start-Fractional-Seconds AVP (AVP Code TBD) is of type 1087 Unsigned32. The value specifies the fractional seconds that are 1088 added to Absolute-Start-Time value in order to deterimine when the 1089 time window starts. If this AVP is absent from the Time-Of-Day- 1090 Condition AVP then the fractional seconds are assumed to be zero. 1092 4.2.9. Absolute-End-Time AVP 1094 The Time-Of-Day-End AVP (AVP Code TBD) is of type Time. The value of 1095 this AVP specifies the time in seconds since January 1, 1900, 00:00 1096 UTC when the time window ends. If this AVP is absent from the Time- 1097 Of-Day-Condition AVP, the time window is open-ended. 1099 4.2.10. Absolute-End-Fractional-Seconds AVP 1101 The Absolute-End-Fractional-Seconds AVP (AVP Code TBD) is of type 1102 Unsigned32. The value specifies the fractional seconds that are 1103 added to Absolute-End-Time value in order to deterimine when the time 1104 window ends. If this AVP is absent from the Time-Of-Day-Condition 1105 AVP then the fractional seconds are assumed to be zero. 1107 4.2.11. Timezone-Flag AVP 1109 The Timezone-Flag AVP (AVP Code TBD) is of type Enumerated and 1110 indicates whether the time windows are specified in UTC, local time 1111 at the managed terminal or as an offset from UTC. If this AVP is 1112 absent from the Time-Of-Day-Condition AVP, the time windows are in 1113 UTC. 1115 This document defines the following values: 1117 Value | Name and Semantic 1118 ------+-------------------------------------------------- 1119 0 | UTC - The time windows are expressed in UTC. 1120 1 | LOCAL - The time windows are expressed in local 1121 | time at the Managed Terminal. 1122 2 | OFFSET - The time windows are expressed as an 1123 | offset from UTC (see Timezone-Offset AVP). 1125 4.2.12. Timezone-Offset AVP 1127 The Timezone-Offset AVP (AVP Code TBD) is of type Integer32. The 1128 value of this AVP MUST be in the range from -43200 to 43200. It 1129 specifies the offset in seconds from UTC that was used to express 1130 Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month- 1131 Mask and Month-Of-Year-Mask AVPs. This AVP MUST be present if the 1132 Timezone-Flag AVP is set to OFFSET. 1134 5. Actions 1136 This section defines the actions associated with a rule. This 1137 document only defines QoS specific actions but further actions can be 1138 specified as extensions. 1140 5.1. QoS-Action AVP 1142 The QoS-Action AVP (AVP Code TBD) is of type Enumerated and lists the 1143 actions that are associated with the condition part of a rule. The 1144 following actions are defined in this document: 1146 0: drop 1147 1: shape 1148 2: mark 1150 drop: 1152 All traffic that is met by the condition part of a rule MUST be 1153 dropped. 1155 shape: 1157 [RFC2475] describes shaping as "the process of delaying packets 1158 within a traffic stream to cause it to conform to some defined 1159 traffic profile". When the action is set to 'shape', the QoS- 1160 Parameters AVP SHALL contain QoS information AVPS that indicate 1161 how to shape the traffic described by the condition part of the 1162 rule. 1164 mark: 1166 [RFC2475] describes marking as "the process of setting the DS 1167 codepoint in a packet based on defined rules". When the action is 1168 set to 'mark', the QoS-Parameters AVP SHALL contain QoS 1169 information AVPS that indicate the DiffServ marking to be applied 1170 to the traffic described by the condition part of the rule. 1172 [RFC2475] also describes an action called "policing" as "the process 1173 of discarding packets (by a dropper) within a traffic stream in 1174 accordance with the state of a corresponding meter enforcing a 1175 traffic profile". This behavior in modeled in the QoS-Rule through 1176 the inclusion of the Excess-Treatment AVP containing a QoS-Action AVP 1177 set to "drop". 1179 Further action values can be registered, as described in 1180 Section 10.3. 1182 5.2. QoS-Profile-Id AVP 1184 The QoS-Profile-Id AVP (AVP Code TBD) is of type Unsigned32 and 1185 contains a QoS profile template identifier. An initial QoS profile 1186 template is defined with value of 0 and can be found in 1187 [I-D.ietf-dime-qos-parameters]. The registry for the QoS profile 1188 templates is created with the same document. 1190 5.3. QoS-Profile-Template AVP 1192 The QoS-Profile-Template AVP (AVP Code TBD) is of type Grouped and 1193 defines the namespace of the QoS profile (indicated in the Vendor-ID 1194 AVP) followed by the specific value for the profile. 1196 The Vendor-Id AVP contains a 32 bit IANA Private Enterprise Number 1197 (PEN) and the QoS-Profile-Id AVP contains the template identifier 1198 assigned by the vendor. The vendor identifier of zero (0) is used 1199 for the IETF. 1201 QoS-Profile-Template ::= < AVP Header: XXX > 1202 { Vendor-Id } 1203 { QoS-Profile-Id } 1204 * [ AVP ] 1206 5.4. QoS-Semantics 1208 The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and 1209 provides the semantics for the QoS-Profile-Template and QoS- 1210 Parameters AVPs in the QoS-Rule AVP. 1212 This document defines the following values: 1214 (0): QoS-Desired 1215 (1): QoS-Available 1216 (2): QoS-Delivered 1217 (3): Minimum-QoS 1218 (4): QoS-Authorized 1220 The semantic of the QoS parameters depend on the information provided 1221 in the list above. The semantics of the different values are as 1222 follows: 1224 Object Type Direction Semantic 1225 --------------------------------------------------------------------- 1226 QoS-Desired C->S Client requests authorization of the 1227 indicated QoS. 1228 QoS-Desired C<-S NA 1229 QoS-Available C->S Admission Control at client indicates 1230 that this QoS is available. (note 1) 1231 QoS-Available C<-S Admission Control at server indicates 1232 that this QoS is available. (note 2) 1233 QoS-Delivered C->S Client is reporting the actual QoS 1234 delivered to the terminal. 1235 QoS-Delivered C<-S NA 1236 Minimum-QoS C->S Client is not interested in authorizing 1237 QoS that is lower than the indicated QoS. 1238 Minimum-QoS C<-S Client must not provide QoS guarantees 1239 lower than the indicated QoS. 1240 QoS-Authorized C->S NA 1241 QoS-Authorized C<-S Server authorizes the indicated QoS. 1243 Legend: 1245 C: Diameter client 1246 S: Diameter server 1247 NA: Not applicable to this document; 1248 no semantic defined in this specification 1250 Notes: 1252 (1) QoS-Available in this direction indicates to the server that 1253 any QoS-Authorized or Minimum-QoS must be less than this 1254 indicated QoS. 1256 (2) QoS-Available in this direction is only useful when the AAA 1257 server performs admission control and knows about the resources 1258 in the network. 1260 5.5. QoS-Parameters AVP 1262 The QoS-Parameters AVP (AVP Code TBD) is of type grouped and contains 1263 Quality of Service parameters. These parameters are defined in 1264 separate documents and depend on the indicated QoS profile template 1265 of the QoS-Profile-Template AVP. For an initial QoS parameter 1266 specification see [I-D.ietf-dime-qos-parameters]. 1268 QoS-Parameters ::= < AVP Header: XXX > 1269 * [ AVP ] 1271 5.6. Excess-Treatment AVP 1273 The Excess-Treatment AVP (AVP Code TBD) is of type grouped and 1274 indicates how out-of-profile traffic, i.e. traffic not covered by the 1275 original QoS-Profile-Template and QoS-Parameters AVPs, is treated. 1276 The additional QoS-Action, QoS-Profile-Template and QoS-Parameters 1277 AVPs carried inside the Excess-Treatment AVP provide information 1278 about the QoS treatment of the excess traffic. In case the Excess- 1279 Treatment AVP is absent then the treatment of the out-of-profile 1280 traffic is left to the discretion of the node performing QoS 1281 treatment. 1283 Excess-Treatment ::= < AVP Header: XXX > 1284 { QoS-Action } 1285 [ QoS-Profile-Template ] 1286 [ QoS-Parameters ] 1287 * [ AVP ] 1289 6. QoS Capability Indication 1291 The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains 1292 a list of supported Quality of Service profile templates (and 1293 therefore the support of the respective parameter AVPs). 1295 The QoS-Capability AVP may be used for a simple announcement of the 1296 QoS capabilities and QoS profiles supported by a peer. It may also 1297 be used to negotiate a mutually supported set of QoS capabilities and 1298 QoS profiles between two peers. In such a case, handling of failed 1299 negotiations is application and/or deployment specific. 1301 QoS-Capability ::= < AVP Header: XXX > 1302 1*{ QoS-Profile-Template } 1303 * [ AVP ] 1305 The QoS-Profile-Template AVP is defined in Section 5.3. 1307 7. Examples 1309 This section shows a number of signaling flows where QoS negotiation 1310 and authorization is part of the conventional NASREQ, EAP or Credit 1311 Control applications message exchanges. The signalling flows for the 1312 Diameter QoS Application are described in 1313 [I-D.ietf-dime-diameter-qos]. 1315 7.1. Diameter EAP with QoS Information 1317 Figure 2 shows a simple signaling flow where a NAS (Diameter Client) 1318 announces its QoS awareness and capabilities included into the DER 1319 message and as part of the access authentication procedure. Upon 1320 completion of the EAP exchange, the Diameter Server provides a pre- 1321 provisioned QoS profile with the QoS-Semantics in the QoS-Rule AVP 1322 set to "QoS-Authorized", to the NAS in the final DEA message. 1324 End Diameter Diameter 1325 Host Client Server 1326 | | | 1327 | (initiate EAP) | | 1328 |<----------------------------->| | 1329 | | Diameter-EAP-Request | 1330 | | EAP-Payload(EAP Start) | 1331 | | QoS-Capability | 1332 | |------------------------------->| 1333 | | | 1334 | | Diameter-EAP-Answer | 1335 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 1336 | | EAP-Payload(EAP Request #1) | 1337 | |<-------------------------------| 1338 | EAP Request(Identity) | | 1339 |<------------------------------| | 1340 : : : 1341 : <<>> : 1342 : : : 1343 | | | 1344 | EAP Response #N | | 1345 |------------------------------>| | 1346 | | Diameter-EAP-Request | 1347 | | EAP-Payload(EAP Response #N) | 1348 | |------------------------------->| 1349 | | | 1350 | | Diameter-EAP-Answer | 1351 | | Result-Code=DIAMETER_SUCCESS | 1352 | | EAP-Payload(EAP Success) | 1353 | | (authorization AVPs) | 1354 | | QoS-Resources(QoS-Authorized) | 1355 | |<-------------------------------| 1356 | | | 1357 | EAP Success | | 1358 |<------------------------------| | 1359 | | | 1361 Figure 2: Example of a Diameter EAP enhanced with QoS Information 1363 7.2. Diameter NASREQ with QoS Information 1365 Figure 3 shows a similar pre-provisioned QoS signaling as in Figure 2 1366 but using the NASREQ application instead of EAP application. 1368 End Diameter 1369 Host NAS Server 1370 | | | 1371 | Start Network | | 1372 | Attachment | | 1373 |<---------------->| | 1374 | | | 1375 | |AA-Request | 1376 | |NASREQ-Payload | 1377 | |QoS-Capability | 1378 | +----------------------------->| 1379 | | | 1380 | | AA-Answer| 1381 | Result-Code=DIAMETER_MULTI_ROUND_AUTH| 1382 | NASREQ-Payload(NASREQ Request #1)| 1383 | |<-----------------------------+ 1384 | | | 1385 | Request | | 1386 |<-----------------+ | 1387 | | | 1388 : : : 1389 : <<>> : 1390 : : : 1391 | Response #N | | 1392 +----------------->| | 1393 | | | 1394 | |AA-Request | 1395 | |NASREQ-Payload ( Response #N )| 1396 | +----------------------------->| 1397 | | | 1398 | | AA-Answer| 1399 | | Result-Code=DIAMETER_SUCCESS| 1400 | | (authorization AVPs)| 1401 | | QoS-Resources(QoS-Authorized)| 1402 | |<-----------------------------+ 1403 | | | 1404 | Success | | 1405 |<-----------------+ | 1406 | | | 1408 Figure 3: Example of a Diameter NASREQ enhanced with QoS Information 1410 7.3. QoS Authorization 1412 Figure 4 shows an example of authorization only QoS signaling as part 1413 of the NASREQ message exchange. The NAS provides the Diameter server 1414 with the "QoS-Desired" QoS-Semantics AVP included in the QoS- 1415 Resources AVP. The Diameter server then either authorizes the 1416 indicated QoS or rejects the request and informs the NAS about the 1417 result. In this scenario the NAS does not need to include the QoS- 1418 Capability AVP in the AAR message as the QoS-Resources AVP implicitly 1419 does the same and also the NAS is authorizing a specific QoS profile, 1420 not a pre-provisioned one. 1422 End Diameter 1423 Host NAS Server 1424 | | | 1425 | | | 1426 | QoS Request | | 1427 +----------------->| | 1428 | | | 1429 | |AA-Request | 1430 | |Auth-Request-Type=AUTHORIZE_ONLY 1431 | |NASREQ-Payload | 1432 | |QoS-Resources(QoS-Desired) | 1433 | +----------------------------->| 1434 | | | 1435 | | AA-Answer| 1436 | | NASREQ-Payload(Success)| 1437 | | QoS-Resources(QoS-Authorized)| 1438 | |<-----------------------------+ 1439 | Accept | | 1440 |<-----------------+ | 1441 | | | 1442 | | | 1443 | | | 1445 Figure 4: Example of an Authorization-Only Message Flow 1447 7.4. Diameter Server Initiated Re-authorization of QoS 1449 Figure 5 shows a message exchange for a Diameter server initiated QoS 1450 re-authorization procedure. The Diameter server sends the NAS a RAR 1451 message requesting re-authorization for an existing session and the 1452 NAS acknowledges it with a RAA message. The NAS is aware of its 1453 existing QoS profile and information for the ongoing session that the 1454 Diameter server requested for re-authorization. Thus, the NAS must 1455 initiate re-authorization of the existing QoS profile. The re- 1456 authorization procedure is the same as in Figure 4. 1458 End Diameter 1459 Host NAS Server 1460 | | | 1461 | | | 1462 : : : 1463 : <<>> : 1464 : : : 1465 | | | 1466 | | RA-Request | 1467 | |<-----------------------------+ 1468 | | | 1469 | |RA-Answer | 1470 | |Result-Code=DIAMETER_SUCCESS | 1471 | +----------------------------->| 1472 | | | 1473 | | | 1474 | |AA-Request | 1475 | |NASREQ-Payload | 1476 | |Auth-Request-Type=AUTHORIZE_ONLY 1477 | |QoS-Resources(QoS-Desired) | 1478 | +----------------------------->| 1479 | | | 1480 | | AA-Answer| 1481 | | Result-Code=DIAMETER_SUCCESS| 1482 | | (authorization AVPs)| 1483 | | QoS-Resources(QoS-Authorized)| 1484 | |<-----------------------------+ 1485 | | | 1487 Figure 5: Example of a Server-initiated Re-Authorization Procedure 1489 7.5. Diameter Credit Control with QoS Information 1491 In this example, the CC client includes a QoS authorization request 1492 (QoS-Semantics=QoS-Desired) in the initial Credit Control 1493 Request(CCR). The CC server responds with a Credit Control Answer 1494 (CCA) which includes the granted resources with an authorized QoS 1495 definition (QoS-Semantics=QoS-Authorized) and the CC client proceeds 1496 to deliver service with the specified QoS. 1498 At the end of service, the CC client reports the units used and the 1499 QoS level at which those units were delivered (QoS-Semantics=QoS- 1500 Delivered). The end of service could occur because the credit 1501 resources granted to the user were exhausted or the service was been 1502 successfully delivered or the service was terminated, e.g. because 1503 the Service Element could not deliver the service at the authorized 1504 QoS level. 1506 Service Element 1507 End User (CC Client) CC Server 1508 | | | 1509 |(1) Service Request | | 1510 |-------------------->| | 1511 | |(2) CCR (Initial, | 1512 | | QoS-Resources(QoS-Desired)) | 1513 | |--------------------------------->| 1514 | |(3) CCA (Granted-Units, | 1515 | | QoS-Resources(QoS-Authorized))| 1516 | |<---------------------------------| 1517 |(4) Service Delivery | | 1518 |<------------------->| | 1519 | | | 1520 |(5) End of Service | | 1521 |-------------------->| | 1522 | |(6) CCR (Termination, Used-Units,| 1523 | | QoS-Rsources(QoS-Delivered)) | 1524 | |--------------------------------->| 1525 | |(7) CCA | 1526 | |<---------------------------------| 1528 Figure 6: Example for a Diameter Credit Control with QoS Information 1530 7.6. Classifier Examples 1532 Example: Classify all packets from hosts on subnet 192.0.2.0/24 to 1533 ports 80, 8090 or 443 on web servers 192.0.2.123, 192.0.2.124, 1534 192.0.2.125. 1536 Classifier = { 1537 Classifier-Id = "web_svr_example"; 1538 Protocol = TCP; 1539 Direction = OUT; 1540 From-Spec = { 1541 IP-Address-Mask = { 1542 IP-Address = 192.0.2.0; 1543 IP-Bit-Mask-Width = 24; 1544 } 1545 } 1546 To-Spec = { 1547 IP-Address = 192.0.2.123; 1548 IP-Address = 192.0.2.124; 1549 IP-Address = 192.0.2.125; 1550 Port = 80; 1551 Port = 8080; 1552 Port = 443; 1553 } 1554 } 1556 Example: Any SIP signalling traffic from a device with a MAC address 1557 of 01:23:45:67:89:ab to servers with IP addresses in the range 1558 192.0.2.90 to 192.0.2.190. 1560 Classifier = { 1561 Classifier-Id = "web_svr_example"; 1562 Protocol = UDP; 1563 Direction = OUT; 1564 From-Spec = { 1565 MAC-Address = 01:23:45:67:89:ab; 1566 } 1567 To-Spec = { 1568 IP-Address-Range = { 1569 IP-Address-Start = 192.0.2.90; 1570 IP-Address-End = 192.0.2.190; 1571 } 1572 Port = 5060; 1573 Port = 3478; 1574 Port-Range = { 1575 Port-Start = 16348; 1576 Port-End = 32768; 1577 } 1578 } 1579 } 1581 7.7. QoS Examples 1583 The following high level description aims to illustrate the 1584 interworking between the Diameter QoS AVPs defined in this document 1585 and the QoS parameters defined in [I-D.ietf-dime-qos-parameters]. 1587 Consider the following example where a rule should be installed that 1588 limits traffic to 1 Mbit/sec and where out-of-profile traffic shall 1589 be dropped.The Classifers are ignored in this example. 1591 This would require the QoS-Action AVP to be set to 'shape' and the 1592 QoS-Parameters AVP carries the Bandwidth AVP indicating the 1 Mbit/ 1593 sec limit. The QoS-Action carried inside the Excess-Treatment AVP 1594 would be set to 'drop'. 1596 In a second, more complex scenario, we consider traffic marking with 1597 DiffServ. In-profile traffic (of 5 Mbits/sec in our example) shall 1598 be associated with a particular PHB-Class "X". Out-of-profile 1599 traffic shall belong to a different PHB-Class, in our example "Y". 1601 This configuration would require the QoS-Action AVP to be set to 1602 'mark'. The QoS-Parameters AVPs for the traffic conforming of the 1603 profile contains two AVPs, namely the TMOD-1 AVP and the PHB-Class 1604 AVP. The TMOD-1 AVP describes the traffic characteristics, namely 5 1605 Mbit/sec, and the PHB-Class AVP is set to class "X". Then, the 1606 Excess-Treatment AVP has to be included with the QoS-Action AVP set 1607 to 'mark' and the QoS-Parameters AVP to carry another PHB-Class AVP 1608 indicating PHB-Class AVP setting to class "Y". 1610 8. Acknowledgments 1612 We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, 1613 Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Tolga 1614 Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina Tsou, 1615 Pete McCann, Georgios Karagiannis, Elwyn Davies, Max Riegel, Yong Li 1616 and Eric Gray for their comments. We thank Victor Fajardo for his 1617 job as PROTO document shepherd. 1619 9. Contributors 1621 Max Riegel contributed the VLAN sections. 1623 10. IANA Considerations 1624 10.1. AVP Codes 1626 IANA is requested to allocate codes from the "AVP Codes" registry 1627 under Authentication, Authorization, and Accounting (AAA) Parameters 1628 for the following AVPs that are defined in this document. 1630 +-------------------------------------------------------------------+ 1631 | AVP Section | 1632 | Attribute Name Code Defined Data Type | 1633 +-------------------------------------------------------------------+ 1634 |QoS-Resources TBD 3.1 Grouped | 1635 |QoS-Rule TBD 3.2 Grouped | 1636 |QoS-Rule-Precedence TBD 3.3 Unsigned32 | 1637 |Classifier TBD 4.1.1 Grouped | 1638 |Classifier-ID TBD 4.1.2 OctetString | 1639 |Protocol TBD 4.1.3 Enumerated | 1640 |Direction TBD 4.1.4 Enumerated | 1641 |From-Spec TBD 4.1.5 Grouped | 1642 |To-Spec TBD 4.1.6 Grouped | 1643 |Negated TBD 4.1.7.1 Enumerated | 1644 |IP-Address TBD 4.1.7.2 Address | 1645 |IP-Address-Range TBD 4.1.7.3 Grouped | 1646 |IP-Address-Start TBD 4.1.7.4 Address | 1647 |IP-Address-End TBD 4.1.7.5 Address | 1648 |IP-Address-Mask TBD 4.1.7.6 Grouped | 1649 |IP-Mask-Bit-Mask-Width TBD 4.1.7.7 Unsigned32 | 1650 |MAC-Address TBD 4.1.7.8 OctetString | 1651 |MAC-Address-Mask TBD 4.1.7.9 Grouped | 1652 |MAC-Address-Mask-Pattern TBD 4.1.7.10 OctetString | 1653 |EUI64-Address TBD 4.1.7.11 OctetString | 1654 |EUI64-Address-Mask TBD 4.1.7.12 Grouped | 1655 |EUI64-Address-Mask-Pattern TBD 4.1.7.13 OctetString | 1656 |Port TBD 4.1.7.14 Integer32 | 1657 |Port-Range TBD 4.1.7.15 Grouped | 1658 |Port-Start TBD 4.1.7.16 Integer32 | 1659 |Port-End TBD 4.1.7.17 Integer32 | 1660 |Use-Assigned-Address TBD 4.1.7.18 Enumerated | 1661 |Diffserv-Code-Point TBD 4.1.8.1 Enumerated | 1662 |Fragmentation-Flag TBD 4.1.8.2 Enumerated | 1663 |IP-Option TBD 4.1.8.3 Grouped | 1664 |IP-Option-Type TBD 4.1.8.4 Enumerated | 1665 |IP-Option-Value TBD 4.1.8.5 OctetString | 1666 |TCP-Option TBD 4.1.8.6 Grouped | 1667 |TCP-Option-Type TBD 4.1.8.7 Enumerated | 1668 |TCP-Option-Value TBD 4.1.8.8 OctetString | 1669 |TCP-Flags TBD 4.1.8.9 Grouped | 1670 |TCP-Flag-Type TBD 4.1.8.10 Unsigned32 | 1671 |ICMP-Type TBD 4.1.8.11 Grouped | 1672 |ICMP-Type-Number TBD 4.1.8.12 Enumerated | 1673 |ICMP-Code TBD 4.1.8.13 Enumerated | 1674 |ETH-Option TBD 4.1.8.14 Grouped | 1675 |ETH-Proto-Type TBD 4.1.8.15 Grouped | 1676 |ETH-Ether-Type TBD 4.1.8.16 OctetString | 1677 |ETH-SAP TBD 4.1.8.17 OctetString | 1678 |VLAN-ID-Range TBD 4.1.8.18 Grouped | 1679 |S-VID-Start TBD 4.1.8.19 Unsigned32 | 1680 |S-VID-End TBD 4.1.8.20 Unsigned32 | 1681 |C-VID-Start TBD 4.1.8.21 Unsigned32 | 1682 |C-VID-End TBD 4.1.8.22 Unsigned32 | 1683 |User-Priority-Range TBD 4.1.8.23 Grouped | 1684 |Low-User-Priority TBD 4.1.8.24 Unsigned32 | 1685 |High-User-Priority TBD 4.1.8.25 Unsigned32 | 1686 |Time-Of-Day-Condition TBD 4.2.1 Grouped | 1687 |Time-Of-Day-Start TBD 4.2.2 Unsigned32 | 1688 |Time-Of-Day-End TBD 4.2.3 Unsigned32 | 1689 |Day-Of-Week-Mask TBD 4.2.4 Unsigned32 | 1690 |Day-Of-Month-Mask TBD 4.2.5 Unsigned32 | 1691 |Month-Of-Year-Mask TBD 4.2.6 Unsigned32 | 1692 |Absolute-Start-Time TBD 4.2.7 Time | 1693 |Absolute-Start-Fractional-Seconds TBD 4.2.8 Unsigned32 | 1694 |Absolute-End-Time TBD 4.2.9 Time | 1695 |Absolute-End-Fractional-Seconds TBD 4.2.10 Unsigned32 | 1696 |Timezone-Flag TBD 4.2.11 Enumerated | 1697 |Timezone-Offset TBD 4.2.12 Integer32 | 1698 |QoS-Action TBD 5.1 Grouped | 1699 |QoS-Profile-Id TBD 5.2 Unsigned32 | 1700 |QoS-Profile-Template TBD 5.3 Grouped | 1701 |QoS-Semantics TBD 5.4 Enumerated | 1702 |QoS-Parameters TBD 5.5 Grouped | 1703 |Excess-Treatment TBD 5.6 Grouped | 1704 |QoS-Capability TBD 6 Grouped | 1705 +-------------------------------------------------------------------+ 1707 10.2. QoS-Semantics IANA Registry 1709 IANA is also requested to allocate a new registry under 1710 Authentication, Authorization, and Accounting (AAA) Parameters for 1711 the QoS-Semantics AVP. The following values are allocated by this 1712 specification: 1714 (0): QoS-Desired 1715 (1): QoS-Available 1716 (2): QoS-Delivered 1717 (3): Minimum-QoS 1718 (4): QoS-Authorized 1720 The definition of new values is subject to the Specification Required 1721 policy [RFC5226]. 1723 10.3. Action 1725 IANA is also requested to allocate a new registry under 1726 Authentication, Authorization, and Accounting (AAA) Parameters for 1727 the QoS-Action AVP. The following values are allocated by this 1728 specification: 1730 0: drop 1731 1: shape 1732 2: mark 1734 The definition of new values is subject to the Specification Required 1735 policy [RFC5226]. 1737 11. Security Considerations 1739 This document describes the extension of Diameter for conveying 1740 Quality of Service information. The security considerations of the 1741 Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. 1742 Use of the AVPs defined in this document MUST take into consideration 1743 the security issues and requirements of the Diameter Base protocol. 1745 12. References 1747 12.1. Normative References 1749 [IEEE802.1D] 1750 IEEE, "IEEE Standard for Local and metropolitan area 1751 networks, Media Access Control (MAC) Bridges", 2004. 1753 [IEEE802.1Q] 1754 IEEE, "IEEE Standard for Local and metropolitan area 1755 networks, Virtual Bridged Local Area Networks", 2005. 1757 [IEEE802.1ad] 1758 IEEE, "IEEE Standard for Local and metropolitan area 1759 networks, Virtual Bridged Local Area Networks, Amendment 1760 4: Provider Bridges", 2005. 1762 [IEEE802.2] 1763 IEEE, "IEEE Standard for Information technology, 1764 Telecommunications and information exchange between 1765 systems, Local and metropolitan area networks, Specific 1766 requirements, Part 2: Logical Link Control", 1998. 1768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1769 Requirement Levels", BCP 14, RFC 2119, March 1997. 1771 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1772 "Definition of the Differentiated Services Field (DS 1773 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1774 December 1998. 1776 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1777 Values In the Internet Protocol and Related Headers", 1778 BCP 37, RFC 2780, March 2000. 1780 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1781 of Explicit Congestion Notification (ECN) to IP", 1782 RFC 3168, September 2001. 1784 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1785 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1787 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1788 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1789 May 2008. 1791 12.2. Informative References 1793 [I-D.ietf-dime-diameter-qos] 1794 Sun, D., McCann, P., Tschofenig, H., ZOU), T., Doria, A., 1795 and G. Zorn, "Diameter Quality of Service Application", 1796 draft-ietf-dime-diameter-qos-12 (work in progress), 1797 October 2009. 1799 [I-D.ietf-dime-qos-parameters] 1800 Korhonen, J., Tschofenig, H., and E. Davies, "Quality of 1801 Service Parameters for Usage with Diameter", 1802 draft-ietf-dime-qos-parameters-11 (work in progress), 1803 May 2009. 1805 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1806 and W. Weiss, "An Architecture for Differentiated 1807 Services", RFC 2475, December 1998. 1809 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1810 "Diameter Network Access Server Application", RFC 4005, 1811 August 2005. 1813 Appendix A. MAC and EUI64 Address Mask Usage Considerations 1815 The MAC and EUI64 address bit masks are generally used in classifying 1816 devices according to OUI and/or address blocks specific to the OUI 1817 assignee. The bit masks are not intended to introduce a structure 1818 into the MAC or EUI64 address space that was not intended by the 1819 IEEE. 1821 The MAC address bit mask should be defined as a contiguous series of 1822 "N" set bits followed by a contiguous series of "48 - N" clear bits, 1823 e.g. the MAC address bit mask of 0xFF00FF000000 would not be valid. 1824 Similarly the EUI64 address bit mask should be defined as a 1825 contiguous series of "N" set bits followed by a contiguous series of 1826 "64 - N" clear bits. 1828 It should also be noted that some OUIs are assigned for use in 1829 applications that require number space management at the organization 1830 level (e.g. - LLC/SNAP encoding), and are not commonly used for MAC 1831 addresses. 1833 Authors' Addresses 1835 Jouni Korhonen 1836 Nokia Siemens Networks 1837 Linnoitustie 6 1838 Espoo 02600 1839 Finland 1841 Email: jouni.korhonen@nsn.com 1843 Hannes Tschofenig 1844 Nokia Siemens Networks 1845 Linnoitustie 6 1846 Espoo 02600 1847 Finland 1849 Phone: +358 (50) 4871445 1850 Email: Hannes.Tschofenig@gmx.net 1851 URI: http://www.tschofenig.priv.at 1852 Mayutan Arumaithurai 1853 University of Goettingen 1855 Email: mayutan.arumaithurai@gmail.com 1857 Mark Jones (editor) 1858 Bridgewater Systems 1859 303 Terry Fox Drive, Suite 500 1860 Ottawa, Ontario K2K 3J1 1861 Canada 1863 Phone: +1 613-591-6655 1864 Email: mark.jones@bridgewatersystems.com 1866 Avi Lior 1867 Bridgewater Systems 1868 303 Terry Fox Drive, Suite 500 1869 Ottawa, Ontario K2K 3J1 1870 Canada 1872 Phone: +1 613-591-6655 1873 Email: avi@bridgewatersystems.com