idnits 2.17.1 draft-ietf-dime-qos-attributes-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (December 18, 2009) is 5240 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-13 -- 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: June 21, 2010 University of Goettingen 7 M. Jones, Ed. 8 A. Lior 9 Bridgewater Systems 10 December 18, 2009 12 Traffic Classification and Quality of Service Attributes for Diameter 13 draft-ietf-dime-qos-attributes-15.txt 15 Abstract 17 This document defines a number of Diameter attribute-value pairs 18 (AVP) for traffic classification with actions for filtering and 19 Quality of Service (QoS) treatment. These AVPs can be used in 20 existing and future Diameter applications where permitted by the 21 Augmented Backus-Naur Form (ABNF) specification of the respective 22 Diameter command extension policy. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on June 21, 2010. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Rule Sets and Rules . . . . . . . . . . . . . . . . . . . . . 6 78 3.1. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 6 79 3.2. Filter-Rule AVP . . . . . . . . . . . . . . . . . . . . . 6 80 3.3. Filter-Rule-Precedence AVP . . . . . . . . . . . . . . . . 7 81 4. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.1. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 8 83 4.1.1. Classifier AVP . . . . . . . . . . . . . . . . . . . . 10 84 4.1.2. Classifier-ID AVP . . . . . . . . . . . . . . . . . . 10 85 4.1.3. Protocol AVP . . . . . . . . . . . . . . . . . . . . . 10 86 4.1.4. Direction AVP . . . . . . . . . . . . . . . . . . . . 10 87 4.1.5. From-Spec AVP . . . . . . . . . . . . . . . . . . . . 11 88 4.1.6. To-Spec AVP . . . . . . . . . . . . . . . . . . . . . 12 89 4.1.7. Source and Destination AVPs . . . . . . . . . . . . . 13 90 4.1.8. Header Option AVPs . . . . . . . . . . . . . . . . . . 17 91 4.2. Time Of Day AVPs . . . . . . . . . . . . . . . . . . . . . 23 92 4.2.1. Time-Of-Day-Condition AVP . . . . . . . . . . . . . . 24 93 4.2.2. Time-Of-Day-Start AVP . . . . . . . . . . . . . . . . 24 94 4.2.3. Time-Of-Day-End AVP . . . . . . . . . . . . . . . . . 24 95 4.2.4. Day-Of-Week-Mask AVP . . . . . . . . . . . . . . . . . 24 96 4.2.5. Day-Of-Month-Mask AVP . . . . . . . . . . . . . . . . 25 97 4.2.6. Month-Of-Year-Mask AVP . . . . . . . . . . . . . . . . 25 98 4.2.7. Absolute-Start-Time AVP . . . . . . . . . . . . . . . 26 99 4.2.8. Absolute-Start-Fractional-Seconds AVP . . . . . . . . 26 100 4.2.9. Absolute-End-Time AVP . . . . . . . . . . . . . . . . 26 101 4.2.10. Absolute-End-Fractional-Seconds AVP . . . . . . . . . 26 102 4.2.11. Timezone-Flag AVP . . . . . . . . . . . . . . . . . . 26 103 4.2.12. Timezone-Offset AVP . . . . . . . . . . . . . . . . . 27 104 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 105 5.1. Treatment-Action AVP . . . . . . . . . . . . . . . . . . . 27 106 5.2. QoS-Profile-Id AVP . . . . . . . . . . . . . . . . . . . . 28 107 5.3. QoS-Profile-Template AVP . . . . . . . . . . . . . . . . . 28 108 5.4. QoS-Semantics . . . . . . . . . . . . . . . . . . . . . . 29 109 5.5. QoS-Parameters AVP . . . . . . . . . . . . . . . . . . . . 30 110 5.6. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 31 111 6. QoS Capability Indication . . . . . . . . . . . . . . . . . . 31 112 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 113 7.1. Diameter EAP with QoS Information . . . . . . . . . . . . 32 114 7.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 33 115 7.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 34 116 7.4. Diameter Server Initiated Re-authorization of QoS . . . . 34 117 7.5. Diameter Credit Control with QoS Information . . . . . . . 35 118 7.6. Classifier Examples . . . . . . . . . . . . . . . . . . . 36 119 7.7. QoS Parameter Examples . . . . . . . . . . . . . . . . . . 38 120 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 121 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 38 122 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 123 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 124 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 125 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41 126 12.2. Informative References . . . . . . . . . . . . . . . . . . 42 127 Appendix A. MAC and EUI64 Address Mask Usage Considerations . . . 43 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 130 1. Introduction 132 This document defines a number of Diameter attribute-value pairs 133 (AVP) for traffic classification with actions for filtering and 134 Quality of Service (QoS) treatment. These AVPs can be used in 135 existing and future Diameter applications where permitted by the 136 Augmented Backus-Naur Form (ABNF) specification of the respective 137 Diameter command extension policy. 139 The work on Quality of Service treatment and filtering via Diameter 140 dates back to the Base protocol described in RFC 3588 [RFC3588]. The 141 filtering and QoS functionality was provided by the IPFilterRule AVP 142 and the QoSFilterRule AVP. Both AVPs relied on syntax based on the 143 FreeBSD ipfw tool for traffic classification. The functionality of 144 the QoSFilterRule AVP was underspecified in RFC 3588 [RFC3588] and 145 was later updated by RFC 4005 [RFC4005]. 147 As part of the work on updating RFC 3588, the functionality of the 148 IPFilterRule and the QoSFilterRule was revised by the functionality 149 offered by this document with the goals of a uniform and extensible 150 traffic classification mechanism in a native Diameter syntax (instead 151 of the free text previously used). Additionally an extensible set of 152 actions is provided that offers the ability for filtering and for QoS 153 treatment, whereby the QoS functionality was extended to meet the 154 needs of today's networking environments. 156 The QoS-Resources AVP represents a complete rule set with each rule 157 represented by a Filter-Rule AVP. Each rule consists of information 158 for handling conflict resolution, a conditions part and the 159 corresponding actions to be performed if the conditions are 160 satisfied. The AVPs responsible for expressing a condition are 161 defined in Section 4. The capability to match all or a subset of the 162 data traffic is provided. This includes the ability to match on 163 Ethernet specific attributes which was not possible with the QoS- 164 Filter-Rule AVP. Service differentiation may be based on Ethernet 165 priority bits, a single layer of VLAN-IDs or stacked VLAN-IDs, LLC 166 attributes, MAC addresses or any combination thereof. The header 167 fields used for Ethernet classification are defined in the IEEE802 168 series of specifications: [IEEE802.2], [IEEE802.1ad], [IEEE802.1Q] 169 and [IEEE802.1D]. Additionally, time-based conditions can be 170 expressed based on the functionality offered by the attributes in 171 Section 4.2. 173 The action part of a rule contains the type of traffic treatment and 174 further description regarding QoS related actions. 176 The QoS policy rules are defined as Diameter encoded Attribute Value 177 Pairs (AVPs) described using a modified version of the Augmented 178 Backus-Naur Form (ABNF), see [RFC3588]. The AVP datatypes are also 179 taken from [RFC3588]. 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 3. Rule Sets and Rules 189 As mentioned in the introduction the top-level element is the QoS- 190 Resources AVP that encapsulates one or more Filter-Rule AVPs. 192 3.1. QoS-Resources AVP 194 The QoS-Resources AVP (AVP Code TBD) is of type Grouped and contains 195 a list of filter policy rules. 197 QoS-Resources ::= < AVP Header: XXX > 198 1*{ Filter-Rule } 199 * [ AVP ] 201 3.2. Filter-Rule AVP 203 The Filter-Rule AVP (AVP Code TBD) is of type Grouped and defines a 204 specific condition and action combination. 206 Filter-Rule ::= < AVP Header: XXX > 207 [ Filter-Rule-Precedence ] 209 ; Condition part of a Rule 210 ; ------------------------ 212 [ Classifier ] 213 * [ Time-Of-Day-Condition ] 215 ; Action and Meta-Data 216 ; -------------------- 218 [ Treatment-Action ] 220 ; Info about QoS related Actions 221 ; ------------------------------ 223 [ QoS-Semantics ] 224 [ QoS-Profile-Template ] 225 [ QoS-Parameters ] 226 [ Excess-Treatment ] 228 ; Extension Point 229 ; --------------- 230 * [ AVP ] 232 If the QoS-Profile-Template AVP is not included in the Filter-Rule 233 AVP and the Treatment-Action AVP is set to 'shape' or 'mark" then the 234 default setting is assumed, namely a setting of the Vendor-Id AVP to 235 0 (for IETF) and the QoS-Profile-Id AVP to zero (0) (for the profile 236 defined in [RFC5624]). Note that the content of the QoS-Parameters 237 are defined in the respective specification defining the QoS 238 parameters. When the Vendor-Id AVP is set to 0 (for IETF) and the 239 QoS-Profile-Id AVP is set to zero (0) then the AVPs included in the 240 QoS-Parameters AVP are the AVPs defined in [RFC5624]. 242 3.3. Filter-Rule-Precedence AVP 244 The Filter-Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 245 and specifies the execution order of the rules expressed in the QoS- 246 Resources AVP. The lower the numerical value of Filter-Rule- 247 Precedence AVP, the higher the rule precedence. Rules with equal 248 precedence MAY be executed in parallel if supported by the Resource 249 Management Function. If the Filter-Rule-Precedence AVP is absent 250 from the Filter-Rule AVP, the rules SHOULD be executed in the order 251 in which they appear in the QoS-Resources AVP. 253 4. Conditions 255 This section describes the condition part of a rule. Two condition 256 types are introduced by this document: packet classification 257 conditions represented by the Classifier AVP and time of day 258 conditions represented by the Time-Of-Day-Condition AVP. 260 If more than one instance of the Time-Of-Day-Condition AVP is present 261 in the Filter-Rule AVP, the current time at rule evaluation MUST be 262 within at least one of the time windows specified in one of the Time- 263 Of-Day-Condition AVPs. 265 When the Time-Of-Day-Condition AVP and Classifier AVP are present in 266 the same Filter-Rule AVP, both the time of day and packet 267 classification conditions MUST match for the traffic treatment action 268 to be applied. 270 4.1. Traffic Classifiers 272 Classifiers are used in many applications to specify how to select a 273 subset of data packets for subsequent treatment as indicated in the 274 action part of a rule. For example in a QoS application, if a packet 275 matches a classifier then that packet will be treated in accordance 276 with a QoS specification associated with that classifier. Figure 1 277 shows a typical deployment. 279 +-----------+ 280 +-----------+| 281 +--------+ +-------------+ +------------+|| 282 | | IN | | | ||| 283 | +--------->| +------------->| ||| 284 |Managed | | Classifying | | Unmanaged ||| 285 |Terminal| OUT | Entity | | Terminal ||| 286 | |<---------+ |<-------------+ ||+ 287 | | | | | |+ 288 +--------+ +-------------+ +------------+ 289 ^ 290 | Classifiers 291 | 292 +------+------+ 293 | | 294 | AAA | 295 | | 296 +-------------+ 298 Figure 1: Example of a Classifier Architecture 300 The managed terminal, the terminal for which the classifiers are 301 being specified is located on the left of the Classifying Entity. 302 The unmanaged terminals, the terminals that receive packets from the 303 Managed terminal or send packets to the managed terminal are located 304 to the right side of the Classifying Entity. 306 The Classifying Entity is responsible for classifying packets that 307 are incoming (IN) from the Managed Terminal or packets outgoing (OUT) 308 to the Managed Terminal. 310 A Classifier consists of a group of attributes that specify how to 311 match a packet. Each set of attributes expresses values about 312 aspects of the packet - typically the packet header. Different 313 protocols therefore would use different attributes. 315 In general a Classifier consists of the following: 317 Identifier: 319 The identifier uniquely identifies this classifier and may be used 320 to reference the classifier from another structure. 322 From: 324 Specifies the rule for matching the protocol specific source 325 address(es) part of the packet. 327 To: 329 Specifies the rule for matching the protocol specific destination 330 address(es) part of the packet. 332 Protocol: 334 Specifies the matching protocol of the packet. 336 Direction: 338 Specifies whether the classifier is to apply to packets flowing 339 from the Managed Terminal (IN) or to packets flowing to the 340 Managed Terminal (OUT), or packets flowing in both direction. 342 Options: 344 Attributes or properties associated with each protocol or layer, 345 or various values specific to the header of the protocol or layer. 346 Options allow matching on those values. 348 Each protocol type will have a specific set of attributes that can be 349 used to specify a classifier for that protocol. These attributes 350 will be grouped under a grouped AVP called a Classifier AVP. 352 4.1.1. Classifier AVP 354 The Classifier AVP (AVP Code TBD) is a grouped AVP that consists of a 355 set of attributes that specify how to match a packet. 357 Classifier ::= < AVP Header: XXX > 358 { Classifier-ID } 359 [ Protocol ] 360 [ Direction ] 361 * [ From-Spec ] 362 * [ To-Spec ] 363 * [ Diffserv-Code-Point ] 364 [ Fragmentation-Flag ] 365 * [ IP-Option ] 366 * [ TCP-Option ] 367 [ TCP-Flags ] 368 * [ ICMP-Type ] 369 * [ ETH-Option ] 370 * [ AVP ] 372 4.1.2. Classifier-ID AVP 374 The Classifier-ID AVP (AVP Code TBD) is of type OctetString and 375 uniquely identifies the classifier. Each application will define the 376 uniqueness scope of this identifier, e.g. unique per terminal or 377 globally unique. Exactly one Classifier-ID AVP MUST be contained 378 within a Classifier AVP. 380 4.1.3. Protocol AVP 382 The Protocol AVP (AVP Code TBD) is of type Enumerated and specifies 383 the protocol being matched. The attributes included in the 384 Classifier AVP MUST be consistent with the value of the Protocol AVP. 385 Exactly zero or one Protocol AVP may be contained within a Classifier 386 AVP. If the Protocol AVP is omitted from the Classifier, then 387 comparison of the protocol of the packet is irrelevant. The values 388 for this AVP are managed by IANA under the Protocol Numbers registry 389 as defined in [RFC2780]. 391 4.1.4. Direction AVP 393 The Direction AVP (AVP Code TBD) is of type Enumerated and specifies 394 in which direction to apply the Classifier. The values of the 395 enumeration are: "IN","OUT","BOTH". In the "IN" and "BOTH" 396 directions, the From-Spec refers to the address of the Managed 397 Terminal and the To-Spec refers to the unmanaged terminal. In the 398 "OUT" direction, the From-Spec refers to the Unmanaged Terminal 399 whereas the To-Spec refers to the Managed Terminal. If the Direction 400 AVP is omitted, the Classifier matches packets flowing in both 401 directions. 403 Value | Name and Semantic 404 ------+-------------------------------------------------- 405 0 | IN - The classifier applies to flows from the 406 | Managed Terminal. 407 1 | OUT - The classifier applies to flows to the 408 | Managed Terminal. 409 2 | BOTH - The classifier applies to flows both to 410 | and from the Managed Terminal. 412 4.1.5. From-Spec AVP 414 The From-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the 415 Source Specification used to match the packet. Zero or more of these 416 AVPs may appear in the Classifier. If this AVP is absent from the 417 Classifier then all packets are matched regardless of the source 418 address. If more than one instance of this AVP appears in the 419 Classifier then the source of the packet can match any From-Spec AVP. 420 The contents of this AVP are protocol specific. 422 If one instance (or multiple instances) of the IP address AVP (IP- 423 Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) 424 appear in the From-Spec AVP then the source IP address of the packet 425 MUST match one of the addresses represented by these AVPs. 427 If more that one instance of the layer 2 address AVPs (MAC-Address, 428 MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the 429 From-Spec then the the source layer 2 address of the packet MUST 430 match one of the addresses represented in these AVPs. 432 If more that one instance of the port AVPs (Port, Port-Range) appears 433 in the From-Spec AVP then the source port number MUST match one of 434 the port numbers represented in these AVPs. 436 If the IP address, MAC address and port AVPs appear in the same From- 437 Spec AVP then the source packet MUST match all the specifications, 438 i.e. match the IP address AND MAC address AND port number. 440 From-Spec ::= < AVP Header: XXX > 441 * [ IP-Address ] 442 * [ IP-Address-Range ] 443 * [ IP-Address-Mask ] 444 * [ MAC-Address ] 445 * [ MAC-Address-Mask] 446 * [ EUI64-Address ] 447 * [ EUI64-Address-Mask] 448 * [ Port ] 449 * [ Port-Range ] 450 [ Negated ] 451 [ Use-Assigned-Address ] 452 * [ AVP ] 454 4.1.6. To-Spec AVP 456 The To-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the 457 Destination Specification used to match the packet. Zero or more of 458 these AVPs may appear in the Classifier. If this AVP is absent from 459 the Classifier then all packets are matched regardless of the 460 destination address. If more than one instance of this AVP appears 461 in the Classifier then the destination of the packet can match any 462 To-Spec AVP. The contents of this AVP are protocol specific. 464 If one instance (or multiple instances) of the IP address AVP (IP- 465 Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) 466 appear in the To-Spec AVP then the destination IP address of the 467 packet MUST match one of the addresses represented by these AVPs. 469 If more that one instance of the layer 2 address AVPs (MAC-Address, 470 MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the 471 To-Spec then the the destination layer 2 address of the packet MUST 472 match one of the addresses represented in these AVPs. 474 If more that one instance of the port AVPs (Port, Port-Range) appears 475 in the To-Spec AVP then the destination port number MUST match one of 476 the port numbers represented in these AVPs. 478 If the IP address, MAC address and port AVPs appear in the same To- 479 Spec AVP then the destination packet MUST match all the 480 specifications, i.e. match the IP address AND MAC address AND port 481 number. 483 To-Spec ::= < AVP Header: XXX > 484 * [ IP-Address ] 485 * [ IP-Address-Range ] 486 * [ IP-Address-Mask ] 487 * [ MAC-Address ] 488 * [ MAC-Address-Mask] 489 * [ EUI64-Address ] 490 * [ EUI64-Address-Mask] 491 * [ Port ] 492 * [ Port-Range ] 493 [ Negated ] 494 [ Use-Assigned-Address ] 495 * [ AVP ] 497 4.1.7. Source and Destination AVPs 499 For packet classification the contents of the From-Spec and To-Spec 500 can contain the AVPs listed in the subsections below. 502 4.1.7.1. Negated AVP 504 The Negated AVP (AVP Code TBD) of type Enumerated containing the 505 values of True or False. Exactly zero or one of these AVPs may 506 appear in the From-Spec or To-Spec AVP. 508 When set to True the meaning of the match is inverted. Addresses 509 other than those in the To-Spec and From-Spec are to be matched 510 instead. When set to False, or when the AVP is not included then the 511 address specified To-Spec and From-Spec AVP are to be matched. 513 Note that the negation does not impact the port comparisons. 515 Value | Name 516 ------+-------- 517 0 | False 518 1 | True 520 4.1.7.2. IP-Address AVP 522 The IP-Address AVP (AVP Code TBD) is of type Address and specifies a 523 single IP address (IPv4 or IPv6) address to match. 525 4.1.7.3. IP-Address-Range AVP 527 The IP-Address-Range AVP (AVP Code TBD) is of type Grouped and 528 specifies an inclusive IP address range. 530 IP-Address-Range ::= < AVP Header: XXX > 531 [ IP-Address-Start ] 532 [ IP-Address-End ] 533 * [ AVP ] 535 If the IP-Address-Start AVP is not included then the address range 536 starts from the first valid IP address up to and including the 537 specified IP-Address-End address. 539 If the IP-Address-End AVP is not included then the address range 540 starts at the address specified by the IP-Address-Start AVP and 541 includes all the remaining valid IP addresses. 543 For the IP-Address-Range AVP to be valid, the IP-Address-Start AVP 544 MUST contain a value that is less than that of the IP-Address-End 545 AVP. 547 4.1.7.4. IP-Address-Start AVP 549 The IP-Address-Start AVP (AVP Code TBD) is of type Address and 550 specifies the first IP address (IPv4 or IPv6) address of an IP 551 address range. 553 4.1.7.5. IP-Address-End AVP 555 The IP-Address-End AVP (AVP Code TBD) is of type Address and 556 specifies the last IP address (IPv4 or IPv6) address of an address 557 range. 559 4.1.7.6. IP-Address-Mask AVP 561 The IP-Address-Mask AVP (AVP Code TBD) is of type Grouped and 562 specifies an IP address range using a base IP address and the bit- 563 width of the mask. For example, a range expressed as 192.0.2.0/24 564 will match all IP addresses from 192.0.2.0 up to and including 565 192.0.2.255. The bit-width MUST be valid for the type of IP address. 567 IP-Address-Mask ::= < AVP Header: XXX > 568 { IP-Address } 569 { IP-Bit-Mask-Width } 570 * [ AVP ] 572 4.1.7.7. IP-Mask-Bit-Mask-Width AVP 574 The IP-Bit-Mask-Width AVP (AVP Code TBD) is of type Unsigned32. The 575 value specifies the width of an IP address bit-mask. 577 4.1.7.8. MAC-Address AVP 579 The MAC-Address AVP (AVP Code TBD) is of type OctetString and 580 specifies a single layer 2 address in MAC-48 format. The value is a 581 6 octets encoding of the address as it would appear in the frame 582 header. 584 4.1.7.9. MAC-Address-Mask AVP 586 The MAC-Address-Mask AVP (AVP Code TBD) is of type Grouped and 587 specifies a set of MAC addresses using a bit mask to indicate the 588 bits of the MAC addresses which must fit to the specified MAC address 589 attribute. For example, a MAC-Address-Mask with the MAC-Address as 590 00-10-A4-23-00-00 and with a MAC-Address-Mask-Pattern of FF-FF-FF-FF- 591 00-00 will match all MAC addresses from 00-10-A4-23-00-00 up to and 592 including 00-10-A4-23-FF-FF. 594 Appendix A describes the considerations that should be given to the 595 use of MAC address masks in constructing Classifiers. 597 MAC-Address-Mask ::= < AVP Header: XXX > 598 { MAC-Address } 599 { MAC-Address-Mask-Pattern } 600 * [ AVP ] 602 4.1.7.10. MAC-Address-Mask-Pattern AVP 604 The MAC-Address-Mask-Pattern AVP (AVP Code TBD) is of type 605 OctetString. The value is a 6 octets specifying the bit positions of 606 a MAC address, that are taken for matching. 608 4.1.7.11. EUI64-Address AVP 610 The EUI64-Address AVP (AVP Code TBD) is of type OctetString and 611 specifies a single layer 2 address in EUI-64 format. The value is a 612 8 octets encoding of the address as it would appear in the frame 613 header. 615 4.1.7.12. EUI64-Address-Mask AVP 617 The EUI64-Address-Mask AVP (AVP Code TBD) is of type Grouped and 618 specifies a set of EUI64 addresses using a bit mask to indicate the 619 bits of the EUI64 addresses which must fit to the specified EUI64 620 address attribute. For example, a EUI64-Address-Mask with the EUI64- 621 Address as 00-10-A4-FF-FE-23-00-00 and with a EUI64-Address-Mask- 622 Pattern of FF-FF-FF-FF-FF-FF-00-00 will match all EUI64 addresses 623 from 00-10-A4-FF-FE-23-00-00 up to and including 00-10-A4-FF-FE-23- 624 FF-FF. 626 Appendix A describes the considerations that should be given to the 627 use of EUI64 address masks in constructing Classifiers. 629 EUI64-Address-Mask ::= < AVP Header: XXX > 630 { EUI64-Address } 631 { EUI64-Address-Mask-Pattern } 632 * [ AVP ] 634 4.1.7.13. EUI64-Address-Mask-Pattern AVP 636 The EUI64-Address-Mask-Pattern AVP (AVP Code TBD) is of type 637 OctetString. The value is a 8 octets specifying the bit positions of 638 a EUI64 address, that are taken for matching. 640 4.1.7.14. Port AVP 642 The Port AVP (AVP Code TBD) is of type Integer32 in the range of 0 to 643 65535 and specifies port numbers to match. The type of port is 644 indicated by the value of the Protocol AVP, i.e. if Procotol AVP 645 value is 6 (TCP) then the Port AVP represents a TCP port. 647 4.1.7.15. Port-Range AVP 649 The Port-Range AVP (AVP Code TBD) is of type Grouped and specifies an 650 inclusive range of ports. The type of the ports is indicated by the 651 value of the Protocol AVP, i.e. if Procotol AVP value is 6 (TCP) then 652 the Port-Range AVP represents an inclusive range of TCP ports. 654 Port-Range ::= < AVP Header: XXX > 655 [ Port-Start ] 656 [ Port-End ] 657 * [ AVP ] 659 If the Port-Start AVP is omitted then port 0 is assumed. If the 660 Port-End AVP is omitted then port 65535 is assumed. 662 4.1.7.16. Port-Start AVP 664 The Port-Start AVP (AVP Code TBD) is of type Integer32 and specifies 665 the first port number of an IP port range. 667 4.1.7.17. Port-End AVP 669 The Port-End AVP (AVP Code TBD) is of type Integer32 and specifies 670 the last port number of an IP port range. 672 4.1.7.18. Use-Assigned-Address AVP 674 In some scenarios, the AAA does not know the IP address assigned to 675 the Managed Terminal at the time that the Classifier is sent to the 676 Classifying Entity. The Use-Assigned-Address AVP (AVP Code TBD) is 677 of type Enumerated containing the values of True or False. When 678 present and set to True, it represents the IP address assigned to the 679 Managed Terminal. 681 Value | Name 682 ------+-------- 683 0 | False 684 1 | True 686 4.1.8. Header Option AVPs 688 The Classifier AVP may contain one or more of the following AVPs to 689 match on the various possible IP, TCP or ICMP header options. 691 4.1.8.1. Diffserv-Code-Point AVP 693 The Diffserv-Code-Point AVP (AVP Code TBD) is of type Enumerated and 694 specifies the Differentiated Services Field Codepoints to match in 695 the IP header. The values are managed by IANA under the 696 Differentiated Services Field Codepoints registry as defined in 697 [RFC2474]. 699 4.1.8.2. Fragmentation-Flag AVP 701 The Fragmentation-Flag AVP (AVP Code TBD) is of type Enumerated and 702 specifies the packet fragmentation flags to match in the IP header. 704 Value | Name and Semantic 705 ------+------------------------------------------------------------ 706 0 | Don't Fragment (DF) 707 1 | More Fragments (MF) 709 4.1.8.3. IP-Option AVP 711 The IP-Option AVP (AVP Code TBD) is of type Grouped and specifies an 712 IP header option that must be matched. 714 IP-Option ::= < AVP Header: XXX > 715 { IP-Option-Type } 716 * [ IP-Option-Value ] 717 [ Negated ] 718 * [ AVP ] 720 If one or more IP-Option-Value AVPs are present, one of the values 721 MUST match the value in the IP header option. If the IP-Option-Value 722 AVP is absent, the option type MUST be present in the IP header but 723 the value is wild carded. 725 The Negated AVP is used in conjunction with the IP-Option-Value AVPs 726 to specify IP header options which do not match specific values. The 727 Negated AVP is used without the IP-Option-Value AVP to specify IP 728 headers which do not contain the option type. 730 4.1.8.4. IP-Option-Type AVP 732 The IP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the 733 values are managed by IANA under the IP Option Numbers registry as 734 defined in [RFC2780]. 736 4.1.8.5. IP-Option-Value AVP 738 The IP-Option-Value AVP (AVP Code TBD) is of type OctetString and 739 contains the option value that must be matched. 741 4.1.8.6. TCP-Option AVP 743 The TCP-Option AVP (AVP Code TBD) is of type Grouped and specifies a 744 TCP header option that must be matched. 746 TCP-Option ::= < AVP Header: XXX > 747 { TCP-Option-Type } 748 * [ TCP-Option-Value ] 749 [ Negated ] 750 * [ AVP ] 752 If one or more TCP-Option-Value AVPs are present, one of the values 753 MUST match the value in the TCP header option. If the TCP-Option- 754 Value AVP is absent, the option type MUST be present in the TCP 755 header but the value is wild carded. 757 The Negated AVP is used in conjunction which the TCP-Option-Value 758 AVPs to specify TCP header options which do not match specific 759 values. The Negated AVP is used without the TCP-Option-Value AVP to 760 specify TCP headers which do not contain the option type. 762 4.1.8.7. TCP-Option-Type AVP 764 The TCP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the 765 values are managed by IANA under the TCP Option Numbers registry as 766 defined in [RFC2780]. 768 4.1.8.8. TCP-Option-Value AVP 770 The TCP-Option-Value AVP (AVP Code TBD) is of type OctetString and 771 contains the option value that must be matched. 773 4.1.8.9. TCP-Flags AVP 775 The TCP-Flags AVP (AVP Code TBD) is of type Grouped and specifies a 776 set of TCP control flags that must be matched. 778 TCP-Flags ::= < AVP Header: XXX > 779 { TCP-Flag-Type } 780 [ Negated ] 781 * [ AVP ] 783 If the Negated AVP is not present or present but set to False, the 784 TCP-Flag-Type AVP specifies which flags MUST be set. If the Negated 785 AVP is set to True, the TCP-Flag-Type AVP specifies which flags MUST 786 be cleared. 788 4.1.8.10. TCP-Flag-Type AVP 790 The TCP-Flag-Type AVP (AVP Code TBD) is of type Unsigned32 and 791 specifies the TCP control flag types that must be matched. The first 792 16 bits match the TCP header format defined in [RFC3168] and the 793 subsequent 16 bits are unused. Within the first 16 bits, bits 0 to 3 794 are unused and bits 4 to 15 are managed by IANA under the TCP Header 795 Flag registry as defined in [RFC3168]. 797 4.1.8.11. ICMP-Type 799 The ICMP-Type AVP (AVP Code TBD) is of type Grouped and specifies a 800 ICMP message type that must be matched. 802 ICMP-Type ::= < AVP Header: XXX > 803 { ICMP-Type-Number } 804 * [ ICMP-Code ] 805 [ Negated ] 806 * [ AVP ] 808 If the ICMP-Code AVP is present, the value MUST match that in the 809 ICMP header. If the ICMP-Code AVP is absent, the ICMP type MUST be 810 present in the ICMP header but the code is wild carded. 812 The Negated AVP is used in conjunction with the ICMP-Code AVPs to 813 specify ICMP codes that do not match specific values. The Negated 814 AVP is used without the ICMP-Code AVP to specify ICMP headers which 815 do not contain the ICMP type. As such, the Negated AVP feature 816 applies to ICMP-Code AVP if the ICMP-Code AVP is present. If the 817 ICMP-Code AVP is absent, the Negated AVP feature applies to the ICMP- 818 Type-Number. 820 4.1.8.12. ICMP-Type-Number AVP 822 The ICMP-Type-Number AVP (AVP Code TBD) is of type Enumerated and the 823 values are managed by IANA under the ICMP Type Numbers registry as 824 defined in [RFC2780]. 826 4.1.8.13. ICMP-Code AVP 828 The ICMP-Code AVP (AVP Code TBD) is of type Enumerated and the values 829 are managed by IANA under the ICMP Type Numbers registry as defined 830 in [RFC2780]. 832 4.1.8.14. ETH-Option AVP 834 The ETH-Option AVP (AVP Code TBD) is of type Grouped and specifies 835 Ethernet specific attributes. 837 ETH-Option ::= < AVP Header: XXX > 838 { ETH-Proto-Type } 839 * [ VLAN-ID-Range ] 840 * [ User-Priority-Range ] 841 * [ AVP ] 843 4.1.8.15. ETH-Proto-Type AVP 845 The Eth-Proto-Type AVP (AVP Code TBD) is of type Grouped and 846 specifies the encapsulated protocol type. ETH-Ether-Type and ETH-SAP 847 are mutually exclusive. 849 ETH-Proto-Type ::= < AVP Header: XXX > 850 * [ ETH-Ether-Type ] 851 * [ ETH-SAP ] 852 * [ AVP ] 854 4.1.8.16. ETH-Ether-Type AVP 856 The ETH-Ether-Type AVP (AVP Code TBD) is of type OctetString. The 857 value is a double octet that contains the value of the Ethertype 858 field in the packet to match. This AVP MAY be present in the case of 859 DIX or if SNAP is present at 802.2 but the ETH-SAP AVP MUST NOT be 860 present in this case. 862 4.1.8.17. ETH-SAP AVP 864 The ETH-SAP AVP (AVP Code TBD) is of type OctetString. The value is 865 a double octet representing the 802.2 SAP as specified in 866 [IEEE802.2]. The first octet contains the DSAP and the second the 867 SSAP. 869 4.1.8.18. VLAN-ID-Range AVP 871 The VLAN-ID-Range AVP (AVP Code TBD) is of type Grouped and specifies 872 the VLAN range to match. VLAN identities are either specified by a 873 single VLAN-ID according to [IEEE802.1Q] or by a combination of 874 Customer and Service VLAN-IDs according to [IEEE802.1ad]. 876 The single VLAN-ID is represented by the C-VID-Start and C-VID-End 877 AVPs and the S-VID-Start and S-VID-End AVPs SHALL be ommitted in this 878 case. If the VLAN-ID-Range AVP is omitted from the Classifier, then 879 comparison of the VLAN identity of the packet is irrelevant. 881 VLAN-ID-Range ::= < AVP Header: XXX > 882 [ S-VID-Start ] 883 [ S-VID-End ] 884 [ C-VID-Start ] 885 [ C-VID-End ] 886 * [ AVP ] 888 The following is the list of possible combinations of the S-VID-Start 889 and S-VID-End AVPs and their inference: 891 o If S-VID-Start AVP is present but the S-VID-End AVP is absent, the 892 S-VID-Start AVP value MUST equal the value of the IEEE 802.1ad 893 S-VID bits specified in [IEEE802.1ad] for a successful match. 894 o If S-VID-Start AVP is absent but the S-VID-End AVP is present, the 895 S-VID-End AVP value MUST equal the value of the IEEE 802.1ad S-VID 896 bits for a successful match. 897 o If both S-VID-Start and S-VID-End AVPs are present and their 898 values are equal, the S-VID-Start AVP value MUST equal the value 899 of the IEEE 802.1ad S-VID bits for a successful match. 901 o If both S-VID-Start and S-VID-End AVPs are present and the value 902 of S-VID-End AVP is greater than the value of the S-VID-Start AVP, 903 the value of the IEEE 802.1ad S-VID bits MUST be greater than or 904 equal to the S-VID- Start AVP value and less than or equal to the 905 S-VID-End AVP value for a successful match. If the S-VID-Start 906 and S-VID-End AVPs are specified, then Ethernet packets without 907 IEEE 802.1ad encapsulation MUST NOT match this Classifier. 908 o If the S-VID-Start and S-VID-End AVPs are omitted, then existence 909 of IEEE802.1ad encapsulation or comparison of the IEEE 802.1ad 910 S-VID bits is irrelevant for this Classifier. 912 The following is the list of possible combinations of the C-VID-Start 913 and C-VID-End AVPs and their inference: 915 o If C-VID-Start AVP is present but the C-VID-End AVP is absent, the 916 C-VID-Start AVP value MUST equal the value of the IEEE 802.1ad 917 C-VID bits specified in [IEEE802.1ad] or the IEEE 802.1Q VLAN-ID 918 bits specified in [IEEE802.1Q] for a successful match. 919 o If C-VID-Start AVP is absent but the C-VID-End AVP is present, the 920 C-VID-End AVP value MUST equal the value of the IEEE 802.1ad C-VID 921 bits or the IEEE 802.1Q VLAN-ID bits for a successful match. 922 o If both C-VID-Start and C-VID-End AVPs are present and their 923 values are equal, the C-VID-Start AVP value MUST equal the value 924 of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits for 925 a successful match. 926 o If both C-VID-Start and C-VID-End AVPs are present and the value 927 of C-VID-End AVP is greater than the value of the C-VID-Start AVP, 928 the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q 929 VLAN-ID bits MUST be greater than or equal to the C-VID-Start AVP 930 value and less than or equal to the C-VID-End AVP value for a 931 successful match. If the C-VID-Start and C-VID-End AVPs are 932 specified, then Ethernet packets without IEEE 802.1ad or IEEE 933 802.1Q encapsulation MUST NOT match this Classifier. 934 o If the C-VID-Start and C-VID-End AVPs are omitted, the comparison 935 of the IEEE 802.1ad C-VID bits or IEEE 802.1Q VLAN-ID bits for 936 this Classifier is irrelevant. 938 4.1.8.19. S-VID-Start AVP 940 The S-VID-Start AVP (AVP Code TBD) is of type Unsigned32. The value 941 MUST be in the range from 0 to 4095. The value of this AVP specifies 942 the start value of the range of S-VID VLAN-IDs to be matched. 944 4.1.8.20. S-VID-End AVP 946 The S-VID-End AVP (AVP Code TBD) is of type Unsigned32. The value 947 MUST be in the range from 0 to 4095. The value of this AVP specifies 948 the end value of the range of S-VID VLAN-IDs to be matched. 950 4.1.8.21. C-VID-Start AVP 952 The C-VID-Start AVP (AVP Code TBD) is of type Unsigned32. The value 953 MUST be in the range from 0 to 4095. The value of this AVP specifies 954 the start value of the range of C-VID VLAN-IDs to be matched. 956 4.1.8.22. C-VID-End AVP 958 The C-VID-End AVP (AVP Code TBD) is of type Unsigned32. The value 959 MUST be in the range from 0 to 4095. The value of this AVP specifies 960 the end value of the range of C-VID VLAN-IDs to be matched. 962 4.1.8.23. User-Priority-Range AVP 964 The User-Priority-Range AVP (AVP Code TBD) is of type Grouped and 965 specifies an inclusive range to match the user_priority parameter 966 specified in [IEEE802.1D]. An Ethernet packet containing the 967 user_priority parameter matches this Classifier if the value is 968 greater than or equal to Low-User-Priority and less than or equal to 969 High-User-Priority. If this AVP is omitted, then comparison of the 970 IEEE 802.1D user_priority parameter for this Classifier is 971 irrelevant. 973 User-Priority-Range ::= < AVP Header: XXX > 974 * [ Low-User-Priority ] 975 * [ High-User-Priority ] 976 * [ AVP ] 978 4.1.8.24. Low-User-Priority AVP 980 The Low-User-Priority AVP (AVP Code TBD) is of type Unsigned32. The 981 value MUST be in the range from 0 to 7. 983 4.1.8.25. High-User-Priority AVP 985 The High-User-Priority AVP (AVP Code TBD) is of type Unsigned32. The 986 value MUST be in the range from 0 to 7. 988 4.2. Time Of Day AVPs 990 In many QoS applications, the QoS specification applied to the 991 traffic flow is conditional upon the time of day when the flow was 992 observed. The following sections define AVPs that can be used to 993 express one or more time windows which determine when a traffic 994 treatment action is applicable to a traffic flow. 996 4.2.1. Time-Of-Day-Condition AVP 998 The Time-Of-Day-Condition AVP (AVP Code TBD) is of type Grouped and 999 specifies one or more time windows. 1001 Time-Of-Day-Condition ::= < AVP Header: XXX > 1002 [ Time-Of-Day-Start ] 1003 [ Time-Of-Day-End ] 1004 [ Day-Of-Week-Mask ] 1005 [ Day-Of-Month-Mask ] 1006 [ Month-Of-Year-Mask ] 1007 [ Absolute-Start-Time ] 1008 [ Absolute-End-Time ] 1009 [ Timezone-Flag ] 1010 * [ AVP ] 1012 For example, a time window for 9am to 5pm (local time) from Monday to 1013 Friday would be expressed as: 1015 Time-Of-Day-Condition = { 1016 Time-Of-Day-Start = 32400; 1017 Time-Of-Day-End = 61200; 1018 Day-Of-Week-Mask = 1019 ( MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY ); 1020 Timezone-Flag = LOCAL; 1021 } 1023 4.2.2. Time-Of-Day-Start AVP 1025 The Time-Of-Day-Start AVP (AVP Code TBD) is of type Unsigned32. The 1026 value MUST be in the range from 0 to 86400. The value of this AVP 1027 specifies the start of an inclusive time window expressed as the 1028 offset in seconds from midnight. If this AVP is absent from the 1029 Time-Of-Day-Condition AVP, the time window starts at midnight. 1031 4.2.3. Time-Of-Day-End AVP 1033 The Time-Of-Day-End AVP (AVP Code TBD) is of type Unsigned32. The 1034 value MUST be in the range from 1 to 86400. The value of this AVP 1035 specifies the end of an inclusive time window expressed as the offset 1036 in seconds from midnight. If this AVP is absent from the Time-Of- 1037 Day-Condition AVP, the time window ends one second before midnight. 1039 4.2.4. Day-Of-Week-Mask AVP 1041 The Day-Of-Week-Mask AVP (AVP Code TBD) is of type Unsigned32. The 1042 value is a bitmask which specifies the day of the week for the time 1043 window to match. This document specifies the following bits: 1045 Bit | Name 1046 ------+------------ 1047 0 | SUNDAY 1048 1 | MONDAY 1049 2 | TUESDAY 1050 3 | WEDNESDAY 1051 4 | THURSDAY 1052 5 | FRIDAY 1053 6 | SATURDAY 1055 The bit MUST be set for the time window to match on the corresponding 1056 day of the week. Bit 0 is the least significant bit and unused bits 1057 MUST be cleared. If this AVP is absent from the Time-Of-Day- 1058 Condition AVP, the time windows match on all days of the week. 1060 4.2.5. Day-Of-Month-Mask AVP 1062 The Day-Of-Month AVP (AVP Code TBD) is of type Unsigned32. The value 1063 MUST be in the range from 0 to 2147483647. The value is a bitmask 1064 which specifies the days of the month where bit 0 represents the 1065 first day of the month through to bit 30 which represents the last 1066 day of the month. The bit MUST be set for the time window to match 1067 on the corresponding day of the month. Bit 0 is the least 1068 significant bit and unused bits MUST be cleared. If this AVP is 1069 absent from the Time-Of-Day-Condition AVP, the time windows match on 1070 all days of the month. 1072 4.2.6. Month-Of-Year-Mask AVP 1074 The Month-Of-Year-Mask AVP (AVP Code TBD) is of type Unsigned32. The 1075 value is a bitmask which specifies the months of the year for the 1076 time window to match. This document specifies the following bits: 1078 Bit | Name 1079 ------+----------- 1080 0 | JANUARY 1081 1 | FEBRUARY 1082 2 | MARCH 1083 3 | APRIL 1084 4 | MAY 1085 5 | JUNE 1086 6 | JULY 1087 7 | AUGUST 1088 8 | SEPTEMBER 1089 9 | OCTOBER 1090 10 | NOVEMBER 1091 11 | DECEMBER 1093 The bit MUST be set for the time window to match on the corresponding 1094 month of the year. Bit 0 is the least significant bit and unused 1095 bits MUST be cleared. If this AVP is absent from the Time-Of-Day- 1096 Condition AVP, the time windows match during all months of the year. 1098 4.2.7. Absolute-Start-Time AVP 1100 The Absolute-Start-Time AVP (AVP Code TBD) is of type Time. The 1101 value of this AVP specifies the time in seconds since January 1, 1102 1900, 00:00 UTC when the time window starts. If this AVP is absent 1103 from the Time-Of-Day-Condition AVP, the time window starts on January 1104 1, 1900, 00:00 UTC. 1106 4.2.8. Absolute-Start-Fractional-Seconds AVP 1108 The Absolute-Start-Fractional-Seconds AVP (AVP Code TBD) is of type 1109 Unsigned32. The value specifies the fractional seconds that are 1110 added to Absolute-Start-Time value in order to deterimine when the 1111 time window starts. If this AVP is absent from the Time-Of-Day- 1112 Condition AVP then the fractional seconds are assumed to be zero. 1114 4.2.9. Absolute-End-Time AVP 1116 The Time-Of-Day-End AVP (AVP Code TBD) is of type Time. The value of 1117 this AVP specifies the time in seconds since January 1, 1900, 00:00 1118 UTC when the time window ends. If this AVP is absent from the Time- 1119 Of-Day-Condition AVP, the time window is open-ended. 1121 4.2.10. Absolute-End-Fractional-Seconds AVP 1123 The Absolute-End-Fractional-Seconds AVP (AVP Code TBD) is of type 1124 Unsigned32. The value specifies the fractional seconds that are 1125 added to Absolute-End-Time value in order to deterimine when the time 1126 window ends. If this AVP is absent from the Time-Of-Day-Condition 1127 AVP then the fractional seconds are assumed to be zero. 1129 4.2.11. Timezone-Flag AVP 1131 The Timezone-Flag AVP (AVP Code TBD) is of type Enumerated and 1132 indicates whether the time windows are specified in UTC, local time 1133 at the managed terminal or as an offset from UTC. If this AVP is 1134 absent from the Time-Of-Day-Condition AVP, the time windows are in 1135 UTC. 1137 This document defines the following values: 1139 Value | Name and Semantic 1140 ------+-------------------------------------------------- 1141 0 | UTC - The time windows are expressed in UTC. 1142 1 | LOCAL - The time windows are expressed in local 1143 | time at the Managed Terminal. 1144 2 | OFFSET - The time windows are expressed as an 1145 | offset from UTC (see Timezone-Offset AVP). 1147 4.2.12. Timezone-Offset AVP 1149 The Timezone-Offset AVP (AVP Code TBD) is of type Integer32. The 1150 value of this AVP MUST be in the range from -43200 to 43200. It 1151 specifies the offset in seconds from UTC that was used to express 1152 Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month- 1153 Mask and Month-Of-Year-Mask AVPs. This AVP MUST be present if the 1154 Timezone-Flag AVP is set to OFFSET. 1156 5. Actions 1158 This section defines the actions associated with a rule. 1160 5.1. Treatment-Action AVP 1162 The Treatment-Action AVP (AVP Code TBD) is of type Enumerated and 1163 lists the actions that are associated with the condition part of a 1164 rule. The following actions are defined in this document: 1166 0: drop 1167 1: shape 1168 2: mark 1169 3: permit 1171 drop: 1173 This action indicates that the respective traffic MUST be dropped. 1175 shape: 1177 [RFC2475] describes shaping as "the process of delaying packets 1178 within a traffic stream to cause it to conform to some defined 1179 traffic profile". When the action is set to 'shape', the QoS- 1180 Parameters AVP SHALL contain QoS information AVPS, such as the 1181 TMOD-1 and Bandwidth AVPs [RFC5624], that indicate how to shape 1182 the traffic described by the condition part of the rule. 1184 mark: 1186 [RFC2475] describes marking as "the process of setting the DS 1187 codepoint in a packet based on defined rules". When the action is 1188 set to 'mark', the QoS-Parameters AVP SHALL contain QoS 1189 information AVPS, such as the PHB-Class AVP [RFC5624], that 1190 indicate the DiffServ marking to be applied to the traffic 1191 described by the condition part of the rule. 1193 permit: 1195 The 'permit' action is the counterpart to the 'drop' action used 1196 to allow traffic that matches the conditions part of a rule to 1197 bypass. 1199 [RFC2475] also describes an action called "policing" as "the process 1200 of discarding packets (by a dropper) within a traffic stream in 1201 accordance with the state of a corresponding meter enforcing a 1202 traffic profile". This behavior in modeled in the Filter-Rule 1203 through the inclusion of the Excess-Treatment AVP containing a 1204 Treatment-Action AVP set to "drop". 1206 Further action values can be registered, as described in 1207 Section 10.3. 1209 5.2. QoS-Profile-Id AVP 1211 The QoS-Profile-Id AVP (AVP Code TBD) is of type Unsigned32 and 1212 contains a QoS profile template identifier. An initial QoS profile 1213 template is defined with value of 0 and can be found in [RFC5624]. 1214 The registry for the QoS profile templates is created with the same 1215 document. 1217 5.3. QoS-Profile-Template AVP 1219 The QoS-Profile-Template AVP (AVP Code TBD) is of type Grouped and 1220 defines the namespace of the QoS profile (indicated in the Vendor-ID 1221 AVP) followed by the specific value for the profile. 1223 The Vendor-Id AVP contains a 32 bit IANA Private Enterprise Number 1224 (PEN) and the QoS-Profile-Id AVP contains the template identifier 1225 assigned by the vendor. The vendor identifier of zero (0) is used 1226 for the IETF. 1228 QoS-Profile-Template ::= < AVP Header: XXX > 1229 { Vendor-Id } 1230 { QoS-Profile-Id } 1231 * [ AVP ] 1233 5.4. QoS-Semantics 1235 The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and 1236 provides the semantics for the QoS-Profile-Template and QoS- 1237 Parameters AVPs in the Filter-Rule AVP. 1239 This document defines the following values: 1241 (0): QoS-Desired 1242 (1): QoS-Available 1243 (2): QoS-Delivered 1244 (3): Minimum-QoS 1245 (4): QoS-Authorized 1247 The semantic of the QoS parameters depend on the information provided 1248 in the list above. The semantics of the different values are as 1249 follows: 1251 Object Type Direction Semantic 1252 --------------------------------------------------------------------- 1253 QoS-Desired C->S Client requests authorization of the 1254 indicated QoS. 1255 QoS-Desired C<-S NA 1256 QoS-Available C->S Admission Control at client indicates 1257 that this QoS is available. (note 1) 1258 QoS-Available C<-S Admission Control at server indicates 1259 that this QoS is available. (note 2) 1260 QoS-Delivered C->S Client is reporting the actual QoS 1261 delivered to the terminal. 1262 QoS-Delivered C<-S NA 1263 Minimum-QoS C->S Client is not interested in authorizing 1264 QoS that is lower than the indicated QoS. 1265 Minimum-QoS C<-S Client must not provide QoS guarantees 1266 lower than the indicated QoS. 1267 QoS-Authorized C->S NA 1268 QoS-Authorized C<-S Server authorizes the indicated QoS. 1270 Legend: 1272 C: Diameter client 1273 S: Diameter server 1274 NA: Not applicable to this document; 1275 no semantic defined in this specification 1277 Notes: 1279 (1) QoS-Available in this direction indicates to the server that 1280 any QoS-Authorized or Minimum-QoS must be less than this 1281 indicated QoS. 1283 (2) QoS-Available in this direction is only useful when the AAA 1284 server performs admission control and knows about the resources 1285 in the network. 1287 5.5. QoS-Parameters AVP 1289 The QoS-Parameters AVP (AVP Code TBD) is of type grouped and contains 1290 Quality of Service parameters. These parameters are defined in 1291 separate documents and depend on the indicated QoS profile template 1292 of the QoS-Profile-Template AVP. For an initial QoS parameter 1293 specification see [RFC5624]. 1295 QoS-Parameters ::= < AVP Header: XXX > 1296 * [ AVP ] 1298 5.6. Excess-Treatment AVP 1300 The Excess-Treatment AVP (AVP Code TBD) is of type grouped and 1301 indicates how out-of-profile traffic, i.e. traffic not covered by the 1302 original QoS-Profile-Template and QoS-Parameters AVPs, is treated. 1303 The additional Treatment-Action, QoS-Profile-Template and QoS- 1304 Parameters AVPs carried inside the Excess-Treatment AVP provide 1305 information about the QoS treatment of the excess traffic. In case 1306 the Excess-Treatment AVP is absent then the treatment of the out-of- 1307 profile traffic is left to the discretion of the node performing QoS 1308 treatment. 1310 Excess-Treatment ::= < AVP Header: XXX > 1311 { Treatment-Action } 1312 [ QoS-Profile-Template ] 1313 [ QoS-Parameters ] 1314 * [ AVP ] 1316 6. QoS Capability Indication 1318 The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains 1319 a list of supported Quality of Service profile templates (and 1320 therefore the support of the respective parameter AVPs). 1322 The QoS-Capability AVP may be used for a simple announcement of the 1323 QoS capabilities and QoS profiles supported by a peer. It may also 1324 be used to negotiate a mutually supported set of QoS capabilities and 1325 QoS profiles between two peers. In such a case, handling of failed 1326 negotiations is application and/or deployment specific. 1328 QoS-Capability ::= < AVP Header: XXX > 1329 1*{ QoS-Profile-Template } 1330 * [ AVP ] 1332 The QoS-Profile-Template AVP is defined in Section 5.3. 1334 7. Examples 1336 This section shows a number of signaling flows where QoS negotiation 1337 and authorization is part of the conventional NASREQ, EAP or Credit 1338 Control applications message exchanges. The signalling flows for the 1339 Diameter QoS Application are described in 1340 [I-D.ietf-dime-diameter-qos]. 1342 7.1. Diameter EAP with QoS Information 1344 Figure 2 shows a simple signaling flow where a NAS (Diameter Client) 1345 announces its QoS awareness and capabilities included into the DER 1346 message and as part of the access authentication procedure. Upon 1347 completion of the EAP exchange, the Diameter Server provides a pre- 1348 provisioned QoS profile with the QoS-Semantics in the Filter-Rule AVP 1349 set to "QoS-Authorized", to the NAS in the final DEA message. 1351 End Diameter Diameter 1352 Host Client Server 1353 | | | 1354 | (initiate EAP) | | 1355 |<----------------------------->| | 1356 | | Diameter-EAP-Request | 1357 | | EAP-Payload(EAP Start) | 1358 | | QoS-Capability | 1359 | |------------------------------->| 1360 | | | 1361 | | Diameter-EAP-Answer | 1362 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 1363 | | EAP-Payload(EAP Request #1) | 1364 | |<-------------------------------| 1365 | EAP Request(Identity) | | 1366 |<------------------------------| | 1367 : : : 1368 : <<>> : 1369 : : : 1370 | | | 1371 | EAP Response #N | | 1372 |------------------------------>| | 1373 | | Diameter-EAP-Request | 1374 | | EAP-Payload(EAP Response #N) | 1375 | |------------------------------->| 1376 | | | 1377 | | Diameter-EAP-Answer | 1378 | | Result-Code=DIAMETER_SUCCESS | 1379 | | EAP-Payload(EAP Success) | 1380 | | (authorization AVPs) | 1381 | | QoS-Resources(QoS-Authorized) | 1382 | |<-------------------------------| 1383 | | | 1384 | EAP Success | | 1385 |<------------------------------| | 1386 | | | 1388 Figure 2: Example of a Diameter EAP enhanced with QoS Information 1390 7.2. Diameter NASREQ with QoS Information 1392 Figure 3 shows a similar pre-provisioned QoS signaling as in Figure 2 1393 but using the NASREQ application instead of EAP application. 1395 End Diameter 1396 Host NAS Server 1397 | | | 1398 | Start Network | | 1399 | Attachment | | 1400 |<---------------->| | 1401 | | | 1402 | |AA-Request | 1403 | |NASREQ-Payload | 1404 | |QoS-Capability | 1405 | +----------------------------->| 1406 | | | 1407 | | AA-Answer| 1408 | Result-Code=DIAMETER_MULTI_ROUND_AUTH| 1409 | NASREQ-Payload(NASREQ Request #1)| 1410 | |<-----------------------------+ 1411 | | | 1412 | Request | | 1413 |<-----------------+ | 1414 | | | 1415 : : : 1416 : <<>> : 1417 : : : 1418 | Response #N | | 1419 +----------------->| | 1420 | | | 1421 | |AA-Request | 1422 | |NASREQ-Payload ( Response #N )| 1423 | +----------------------------->| 1424 | | | 1425 | | AA-Answer| 1426 | | Result-Code=DIAMETER_SUCCESS| 1427 | | (authorization AVPs)| 1428 | | QoS-Resources(QoS-Authorized)| 1429 | |<-----------------------------+ 1430 | | | 1431 | Success | | 1432 |<-----------------+ | 1433 | | | 1435 Figure 3: Example of a Diameter NASREQ enhanced with QoS Information 1437 7.3. QoS Authorization 1439 Figure 4 shows an example of authorization only QoS signaling as part 1440 of the NASREQ message exchange. The NAS provides the Diameter server 1441 with the "QoS-Desired" QoS-Semantics AVP included in the QoS- 1442 Resources AVP. The Diameter server then either authorizes the 1443 indicated QoS or rejects the request and informs the NAS about the 1444 result. In this scenario the NAS does not need to include the QoS- 1445 Capability AVP in the AAR message as the QoS-Resources AVP implicitly 1446 does the same and also the NAS is authorizing a specific QoS profile, 1447 not a pre-provisioned one. 1449 End Diameter 1450 Host NAS Server 1451 | | | 1452 | | | 1453 | QoS Request | | 1454 +----------------->| | 1455 | | | 1456 | |AA-Request | 1457 | |Auth-Request-Type=AUTHORIZE_ONLY 1458 | |NASREQ-Payload | 1459 | |QoS-Resources(QoS-Desired) | 1460 | +----------------------------->| 1461 | | | 1462 | | AA-Answer| 1463 | | NASREQ-Payload(Success)| 1464 | | QoS-Resources(QoS-Authorized)| 1465 | |<-----------------------------+ 1466 | Accept | | 1467 |<-----------------+ | 1468 | | | 1469 | | | 1470 | | | 1472 Figure 4: Example of an Authorization-Only Message Flow 1474 7.4. Diameter Server Initiated Re-authorization of QoS 1476 Figure 5 shows a message exchange for a Diameter server initiated QoS 1477 re-authorization procedure. The Diameter server sends the NAS a RAR 1478 message requesting re-authorization for an existing session and the 1479 NAS acknowledges it with a RAA message. The NAS is aware of its 1480 existing QoS profile and information for the ongoing session that the 1481 Diameter server requested for re-authorization. Thus, the NAS must 1482 initiate re-authorization of the existing QoS profile. The re- 1483 authorization procedure is the same as in Figure 4. 1485 End Diameter 1486 Host NAS Server 1487 | | | 1488 | | | 1489 : : : 1490 : <<>> : 1491 : : : 1492 | | | 1493 | | RA-Request | 1494 | |<-----------------------------+ 1495 | | | 1496 | |RA-Answer | 1497 | |Result-Code=DIAMETER_SUCCESS | 1498 | +----------------------------->| 1499 | | | 1500 | | | 1501 | |AA-Request | 1502 | |NASREQ-Payload | 1503 | |Auth-Request-Type=AUTHORIZE_ONLY 1504 | |QoS-Resources(QoS-Desired) | 1505 | +----------------------------->| 1506 | | | 1507 | | AA-Answer| 1508 | | Result-Code=DIAMETER_SUCCESS| 1509 | | (authorization AVPs)| 1510 | | QoS-Resources(QoS-Authorized)| 1511 | |<-----------------------------+ 1512 | | | 1514 Figure 5: Example of a Server-initiated Re-Authorization Procedure 1516 7.5. Diameter Credit Control with QoS Information 1518 In this example, the CC client includes a QoS authorization request 1519 (QoS-Semantics=QoS-Desired) in the initial Credit Control 1520 Request(CCR). The CC server responds with a Credit Control Answer 1521 (CCA) which includes the granted resources with an authorized QoS 1522 definition (QoS-Semantics=QoS-Authorized) and the CC client proceeds 1523 to deliver service with the specified QoS. 1525 At the end of service, the CC client reports the units used and the 1526 QoS level at which those units were delivered (QoS-Semantics=QoS- 1527 Delivered). The end of service could occur because the credit 1528 resources granted to the user were exhausted or the service was been 1529 successfully delivered or the service was terminated, e.g. because 1530 the Service Element could not deliver the service at the authorized 1531 QoS level. 1533 Service Element 1534 End User (CC Client) CC Server 1535 | | | 1536 |(1) Service Request | | 1537 |-------------------->| | 1538 | |(2) CCR (Initial, | 1539 | | QoS-Resources(QoS-Desired)) | 1540 | |--------------------------------->| 1541 | |(3) CCA (Granted-Units, | 1542 | | QoS-Resources(QoS-Authorized))| 1543 | |<---------------------------------| 1544 |(4) Service Delivery | | 1545 |<------------------->| | 1546 | | | 1547 |(5) End of Service | | 1548 |-------------------->| | 1549 | |(6) CCR (Termination, Used-Units,| 1550 | | QoS-Rsources(QoS-Delivered)) | 1551 | |--------------------------------->| 1552 | |(7) CCA | 1553 | |<---------------------------------| 1555 Figure 6: Example for a Diameter Credit Control with QoS Information 1557 7.6. Classifier Examples 1559 Example: Classify all packets from hosts on subnet 192.0.2.0/24 to 1560 ports 80, 8090 or 443 on web servers 192.0.2.123, 192.0.2.124, 1561 192.0.2.125. 1563 Classifier = { 1564 Classifier-Id = "web_svr_example"; 1565 Protocol = TCP; 1566 Direction = OUT; 1567 From-Spec = { 1568 IP-Address-Mask = { 1569 IP-Address = 192.0.2.0; 1570 IP-Bit-Mask-Width = 24; 1571 } 1572 } 1573 To-Spec = { 1574 IP-Address = 192.0.2.123; 1575 IP-Address = 192.0.2.124; 1576 IP-Address = 192.0.2.125; 1577 Port = 80; 1578 Port = 8080; 1579 Port = 443; 1580 } 1581 } 1583 Example: Any SIP signalling traffic from a device with a MAC address 1584 of 01:23:45:67:89:ab to servers with IP addresses in the range 1585 192.0.2.90 to 192.0.2.190. 1587 Classifier = { 1588 Classifier-Id = "web_svr_example"; 1589 Protocol = UDP; 1590 Direction = OUT; 1591 From-Spec = { 1592 MAC-Address = 01:23:45:67:89:ab; 1593 } 1594 To-Spec = { 1595 IP-Address-Range = { 1596 IP-Address-Start = 192.0.2.90; 1597 IP-Address-End = 192.0.2.190; 1598 } 1599 Port = 5060; 1600 Port = 3478; 1601 Port-Range = { 1602 Port-Start = 16348; 1603 Port-End = 32768; 1604 } 1605 } 1606 } 1608 7.7. QoS Parameter Examples 1610 The following high level description aims to illustrate the 1611 interworking between the Diameter QoS AVPs defined in this document 1612 and the QoS parameters defined in [RFC5624]. 1614 Consider the following example where a rule should be installed that 1615 limits traffic to 1 Mbit/sec and where out-of-profile traffic shall 1616 be dropped.The Classifers are ignored in this example. 1618 This would require the Treatment-Action AVP to be set to 'shape' and 1619 the QoS-Parameters AVP carries the Bandwidth AVP indicating the 1 1620 Mbit/sec limit. The Treatment-Action carried inside the Excess- 1621 Treatment AVP would be set to 'drop'. 1623 In a second, more complex scenario, we consider traffic marking with 1624 DiffServ. In-profile traffic (of 5 Mbits/sec in our example) shall 1625 be associated with a particular PHB-Class "X". Out-of-profile 1626 traffic shall belong to a different PHB-Class, in our example "Y". 1628 This configuration would require the Treatment-Action AVP to be set 1629 to 'mark'. The QoS-Parameters AVPs for the traffic conforming of the 1630 profile contains two AVPs, namely the TMOD-1 AVP and the PHB-Class 1631 AVP. The TMOD-1 AVP describes the traffic characteristics, namely 5 1632 Mbit/sec, and the PHB-Class AVP is set to class "X". Then, the 1633 Excess-Treatment AVP has to be included with the Treatment-Action AVP 1634 set to 'mark' and the QoS-Parameters AVP to carry another PHB-Class 1635 AVP indicating PHB-Class AVP setting to class "Y". 1637 8. Acknowledgments 1639 We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, 1640 Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Tolga 1641 Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina Tsou, 1642 Pete McCann, Georgios Karagiannis, Elwyn Davies, Max Riegel, Yong Li 1643 and Eric Gray for their comments. We thank Victor Fajardo for his 1644 job as PROTO document shepherd. Finally, we would like to thank Lars 1645 Eggert, Magnus Westerlund, Adrian Farrel, Lisa Dusseault, Ralph 1646 Droms, and Eric Gray for their feedback during the IESG review phase. 1648 9. Contributors 1650 Max Riegel contributed the VLAN sections. 1652 10. IANA Considerations 1654 10.1. AVP Codes 1656 IANA is requested to allocate codes from the "AVP Codes" registry 1657 under Authentication, Authorization, and Accounting (AAA) Parameters 1658 for the following AVPs that are defined in this document. 1660 +-------------------------------------------------------------------+ 1661 | AVP Section | 1662 | Attribute Name Code Defined Data Type | 1663 +-------------------------------------------------------------------+ 1664 |QoS-Resources TBD 3.1 Grouped | 1665 |Filter-Rule TBD 3.2 Grouped | 1666 |Filter-Rule-Precedence TBD 3.3 Unsigned32 | 1667 |Classifier TBD 4.1.1 Grouped | 1668 |Classifier-ID TBD 4.1.2 OctetString | 1669 |Protocol TBD 4.1.3 Enumerated | 1670 |Direction TBD 4.1.4 Enumerated | 1671 |From-Spec TBD 4.1.5 Grouped | 1672 |To-Spec TBD 4.1.6 Grouped | 1673 |Negated TBD 4.1.7.1 Enumerated | 1674 |IP-Address TBD 4.1.7.2 Address | 1675 |IP-Address-Range TBD 4.1.7.3 Grouped | 1676 |IP-Address-Start TBD 4.1.7.4 Address | 1677 |IP-Address-End TBD 4.1.7.5 Address | 1678 |IP-Address-Mask TBD 4.1.7.6 Grouped | 1679 |IP-Mask-Bit-Mask-Width TBD 4.1.7.7 Unsigned32 | 1680 |MAC-Address TBD 4.1.7.8 OctetString | 1681 |MAC-Address-Mask TBD 4.1.7.9 Grouped | 1682 |MAC-Address-Mask-Pattern TBD 4.1.7.10 OctetString | 1683 |EUI64-Address TBD 4.1.7.11 OctetString | 1684 |EUI64-Address-Mask TBD 4.1.7.12 Grouped | 1685 |EUI64-Address-Mask-Pattern TBD 4.1.7.13 OctetString | 1686 |Port TBD 4.1.7.14 Integer32 | 1687 |Port-Range TBD 4.1.7.15 Grouped | 1688 |Port-Start TBD 4.1.7.16 Integer32 | 1689 |Port-End TBD 4.1.7.17 Integer32 | 1690 |Use-Assigned-Address TBD 4.1.7.18 Enumerated | 1691 |Diffserv-Code-Point TBD 4.1.8.1 Enumerated | 1692 |Fragmentation-Flag TBD 4.1.8.2 Enumerated | 1693 |IP-Option TBD 4.1.8.3 Grouped | 1694 |IP-Option-Type TBD 4.1.8.4 Enumerated | 1695 |IP-Option-Value TBD 4.1.8.5 OctetString | 1696 |TCP-Option TBD 4.1.8.6 Grouped | 1697 |TCP-Option-Type TBD 4.1.8.7 Enumerated | 1698 |TCP-Option-Value TBD 4.1.8.8 OctetString | 1699 |TCP-Flags TBD 4.1.8.9 Grouped | 1700 |TCP-Flag-Type TBD 4.1.8.10 Unsigned32 | 1701 |ICMP-Type TBD 4.1.8.11 Grouped | 1702 |ICMP-Type-Number TBD 4.1.8.12 Enumerated | 1703 |ICMP-Code TBD 4.1.8.13 Enumerated | 1704 |ETH-Option TBD 4.1.8.14 Grouped | 1705 |ETH-Proto-Type TBD 4.1.8.15 Grouped | 1706 |ETH-Ether-Type TBD 4.1.8.16 OctetString | 1707 |ETH-SAP TBD 4.1.8.17 OctetString | 1708 |VLAN-ID-Range TBD 4.1.8.18 Grouped | 1709 |S-VID-Start TBD 4.1.8.19 Unsigned32 | 1710 |S-VID-End TBD 4.1.8.20 Unsigned32 | 1711 |C-VID-Start TBD 4.1.8.21 Unsigned32 | 1712 |C-VID-End TBD 4.1.8.22 Unsigned32 | 1713 |User-Priority-Range TBD 4.1.8.23 Grouped | 1714 |Low-User-Priority TBD 4.1.8.24 Unsigned32 | 1715 |High-User-Priority TBD 4.1.8.25 Unsigned32 | 1716 |Time-Of-Day-Condition TBD 4.2.1 Grouped | 1717 |Time-Of-Day-Start TBD 4.2.2 Unsigned32 | 1718 |Time-Of-Day-End TBD 4.2.3 Unsigned32 | 1719 |Day-Of-Week-Mask TBD 4.2.4 Unsigned32 | 1720 |Day-Of-Month-Mask TBD 4.2.5 Unsigned32 | 1721 |Month-Of-Year-Mask TBD 4.2.6 Unsigned32 | 1722 |Absolute-Start-Time TBD 4.2.7 Time | 1723 |Absolute-Start-Fractional-Seconds TBD 4.2.8 Unsigned32 | 1724 |Absolute-End-Time TBD 4.2.9 Time | 1725 |Absolute-End-Fractional-Seconds TBD 4.2.10 Unsigned32 | 1726 |Timezone-Flag TBD 4.2.11 Enumerated | 1727 |Timezone-Offset TBD 4.2.12 Integer32 | 1728 |Treatment-Action TBD 5.1 Grouped | 1729 |QoS-Profile-Id TBD 5.2 Unsigned32 | 1730 |QoS-Profile-Template TBD 5.3 Grouped | 1731 |QoS-Semantics TBD 5.4 Enumerated | 1732 |QoS-Parameters TBD 5.5 Grouped | 1733 |Excess-Treatment TBD 5.6 Grouped | 1734 |QoS-Capability TBD 6 Grouped | 1735 +-------------------------------------------------------------------+ 1737 10.2. QoS-Semantics IANA Registry 1739 IANA is also requested to allocate a new registry under 1740 Authentication, Authorization, and Accounting (AAA) Parameters for 1741 the QoS-Semantics AVP. The following values are allocated by this 1742 specification: 1744 (0): QoS-Desired 1745 (1): QoS-Available 1746 (2): QoS-Delivered 1747 (3): Minimum-QoS 1748 (4): QoS-Authorized 1750 The definition of new values is subject to the Specification Required 1751 policy [RFC5226]. 1753 10.3. Action 1755 IANA is also requested to allocate a new registry under 1756 Authentication, Authorization, and Accounting (AAA) Parameters for 1757 the Treatment-Action AVP. The following values are allocated by this 1758 specification: 1760 0: drop 1761 1: shape 1762 2: mark 1763 3: permit 1765 The definition of new values is subject to the Specification Required 1766 policy [RFC5226]. 1768 11. Security Considerations 1770 This document describes the extension of Diameter for conveying 1771 Quality of Service information. The security considerations of the 1772 Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. 1773 Use of the AVPs defined in this document MUST take into consideration 1774 the security issues and requirements of the Diameter Base protocol. 1776 12. References 1778 12.1. Normative References 1780 [IEEE802.1D] 1781 IEEE, "IEEE Standard for Local and metropolitan area 1782 networks, Media Access Control (MAC) Bridges", 2004. 1784 [IEEE802.1Q] 1785 IEEE, "IEEE Standard for Local and metropolitan area 1786 networks, Virtual Bridged Local Area Networks", 2005. 1788 [IEEE802.1ad] 1789 IEEE, "IEEE Standard for Local and metropolitan area 1790 networks, Virtual Bridged Local Area Networks, Amendment 1791 4: Provider Bridges", 2005. 1793 [IEEE802.2] 1794 IEEE, "IEEE Standard for Information technology, 1795 Telecommunications and information exchange between 1796 systems, Local and metropolitan area networks, Specific 1797 requirements, Part 2: Logical Link Control", 1998. 1799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1800 Requirement Levels", BCP 14, RFC 2119, March 1997. 1802 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1803 "Definition of the Differentiated Services Field (DS 1804 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1805 December 1998. 1807 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1808 Values In the Internet Protocol and Related Headers", 1809 BCP 37, RFC 2780, March 2000. 1811 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1812 of Explicit Congestion Notification (ECN) to IP", 1813 RFC 3168, September 2001. 1815 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1816 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1818 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1819 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1820 May 2008. 1822 12.2. Informative References 1824 [I-D.ietf-dime-diameter-qos] 1825 Sun, D., McCann, P., Tschofenig, H., ZOU), T., Doria, A., 1826 and G. Zorn, "Diameter Quality of Service Application", 1827 draft-ietf-dime-diameter-qos-13 (work in progress), 1828 October 2009. 1830 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1831 and W. Weiss, "An Architecture for Differentiated 1832 Services", RFC 2475, December 1998. 1834 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1835 "Diameter Network Access Server Application", RFC 4005, 1836 August 2005. 1838 [RFC5624] Korhonen, J., Tschofenig, H., and E. Davies, "Quality of 1839 Service Parameters for Usage with Diameter", RFC 5624, 1840 August 2009. 1842 Appendix A. MAC and EUI64 Address Mask Usage Considerations 1844 The MAC and EUI64 address bit masks are generally used in classifying 1845 devices according to OUI and/or address blocks specific to the OUI 1846 assignee. The bit masks are not intended to introduce a structure 1847 into the MAC or EUI64 address space that was not intended by the 1848 IEEE. 1850 The MAC address bit mask should be defined as a contiguous series of 1851 "N" set bits followed by a contiguous series of "48 - N" clear bits, 1852 e.g. the MAC address bit mask of 0xFF00FF000000 would not be valid. 1853 Similarly the EUI64 address bit mask should be defined as a 1854 contiguous series of "N" set bits followed by a contiguous series of 1855 "64 - N" clear bits. 1857 It should also be noted that some OUIs are assigned for use in 1858 applications that require number space management at the organization 1859 level (e.g. - LLC/SNAP encoding), and are not commonly used for MAC 1860 addresses. 1862 Authors' Addresses 1864 Jouni Korhonen 1865 Nokia Siemens Networks 1866 Linnoitustie 6 1867 Espoo 02600 1868 Finland 1870 Email: jouni.korhonen@nsn.com 1872 Hannes Tschofenig 1873 Nokia Siemens Networks 1874 Linnoitustie 6 1875 Espoo 02600 1876 Finland 1878 Phone: +358 (50) 4871445 1879 Email: Hannes.Tschofenig@gmx.net 1880 URI: http://www.tschofenig.priv.at 1881 Mayutan Arumaithurai 1882 University of Goettingen 1884 Email: mayutan.arumaithurai@gmail.com 1886 Mark Jones (editor) 1887 Bridgewater Systems 1888 303 Terry Fox Drive, Suite 500 1889 Ottawa, Ontario K2K 3J1 1890 Canada 1892 Phone: +1 613-591-6655 1893 Email: mark.jones@bridgewatersystems.com 1895 Avi Lior 1896 Bridgewater Systems 1897 303 Terry Fox Drive, Suite 500 1898 Ottawa, Ontario K2K 3J1 1899 Canada 1901 Phone: +1 613-591-6655 1902 Email: avi@bridgewatersystems.com