idnits 2.17.1 draft-ietf-dime-qos-attributes-12.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 (June 5, 2009) is 5411 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 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-08 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 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: December 7, 2009 University of Goettingen 7 M. Jones, Ed. 8 A. Lior 9 Bridgewater Systems 10 June 5, 2009 12 Quality of Service Attributes for Diameter 13 draft-ietf-dime-qos-attributes-12.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 December 7, 2009. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This document extends the IPFilterRule AVP functionality of the 61 Diameter Base protocol and the functionality of the QoS-Filter-Rule 62 AVP defined in RFC 4005. The ability to convey Quality of Service 63 information using the AVPs defined in this document is available to 64 existing and future Diameter applications where permitted by the 65 command ABNF. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Rule Sets and Rules . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 5 73 3.2. QoS-Rule AVP . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.3. QoS-Rule-Precedence AVP . . . . . . . . . . . . . . . . . 6 75 4. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 7 77 4.1.1. Classifier AVP . . . . . . . . . . . . . . . . . . . . 9 78 4.1.2. Classifier-ID AVP . . . . . . . . . . . . . . . . . . 10 79 4.1.3. Protocol AVP . . . . . . . . . . . . . . . . . . . . . 10 80 4.1.4. Direction AVP . . . . . . . . . . . . . . . . . . . . 10 81 4.1.5. From-Spec AVP . . . . . . . . . . . . . . . . . . . . 10 82 4.1.6. To-Spec AVP . . . . . . . . . . . . . . . . . . . . . 11 83 4.1.7. Source and Destination AVPs . . . . . . . . . . . . . 12 84 4.1.8. Header Option AVPs . . . . . . . . . . . . . . . . . . 16 85 4.2. Time Of Day AVPs . . . . . . . . . . . . . . . . . . . . . 23 86 4.2.1. Time-Of-Day-Condition AVP . . . . . . . . . . . . . . 23 87 4.2.2. Time-Of-Day-Start AVP . . . . . . . . . . . . . . . . 24 88 4.2.3. Time-Of-Day-End AVP . . . . . . . . . . . . . . . . . 24 89 4.2.4. Day-Of-Week-Mask AVP . . . . . . . . . . . . . . . . . 24 90 4.2.5. Day-Of-Month-Mask AVP . . . . . . . . . . . . . . . . 25 91 4.2.6. Month-Of-Year-Mask AVP . . . . . . . . . . . . . . . . 25 92 4.2.7. Absolute-Start-Time AVP . . . . . . . . . . . . . . . 25 93 4.2.8. Absolute-End-Time AVP . . . . . . . . . . . . . . . . 26 94 4.2.9. Timezone-Flag AVP . . . . . . . . . . . . . . . . . . 26 95 4.2.10. Timezone-Offset AVP . . . . . . . . . . . . . . . . . 26 96 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 5.1. QoS-Action AVP . . . . . . . . . . . . . . . . . . . . . . 26 98 5.2. QoS-Profile-Id AVP . . . . . . . . . . . . . . . . . . . . 27 99 5.3. QoS-Profile-Template AVP . . . . . . . . . . . . . . . . . 27 100 5.4. QoS-Semantics . . . . . . . . . . . . . . . . . . . . . . 28 101 5.5. QoS-Parameters AVP . . . . . . . . . . . . . . . . . . . . 29 102 5.6. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 29 103 6. QoS Capability Indication . . . . . . . . . . . . . . . . . . 30 104 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 105 7.1. Diameter EAP with QoS Information . . . . . . . . . . . . 30 106 7.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 31 107 7.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 32 108 7.4. Diameter Server Initiated Re-authorization of QoS . . . . 33 109 7.5. Diameter Credit Control with QoS Information . . . . . . . 34 110 7.6. Classifier Examples . . . . . . . . . . . . . . . . . . . 35 111 7.7. QoS Examples . . . . . . . . . . . . . . . . . . . . . . . 36 112 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 113 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37 114 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 115 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 116 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 117 12.1. Normative References . . . . . . . . . . . . . . . . . . . 40 118 12.2. Informative References . . . . . . . . . . . . . . . . . . 40 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 121 1. Introduction 123 This document defines a number of Diameter Quality of Service (QoS) 124 related AVPs that can be used in existing and future Diameter 125 applications where permitted by the ABNF of a command. The 126 IPFilterRule AVP, defined in RFC 3588 [RFC3588], and the QoS-Filter- 127 Rule AVP, defined in RFC 4005 [RFC4005], provide basic support for 128 classification and QoS already. The classification rule syntax is a 129 modified subset of FreeBSD ipfw packet filter implementation. The 130 QoS functionality provided by the IPFilterRule AVP was updated by the 131 QoS-Filter-Rule AVP. The QoS-Rule AVP offers an extended way of 132 expressing classification and QoS capabilities. 134 The QoS-Resources AVP represents a complete rule set with each rule 135 represented by a QoS-Rule AVP. Each rule consists of a conditions 136 part and the corresponding actions to be performed if the conditions 137 are satisfied. The AVPs responsible for expressing a condition are 138 defined in Section 4. Capabilities to match all or a subset of the 139 data traffic is provided. Additionally, time-based conditions can be 140 expressed based on the functionality offered in Section 4.2. The 141 action part of a rule contains information for handling conflict 142 resolution, such as a priority value for each individual rule within 143 a rule set, and further description regarding QoS related actions. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 3. Rule Sets and Rules 153 As mentioned in the introduction the top-level element is the QoS- 154 Resources AVP that encapsulates one or more QoS-Rule AVPs. 156 3.1. QoS-Resources AVP 158 The QoS-Resources AVP (AVP Code TBD) is of type Grouped and describes 159 a list of policies. 161 QoS-Resources ::= < AVP Header: XXX > 162 1*{ QoS-Rule } 163 * [ AVP ] 165 3.2. QoS-Rule AVP 167 The QoS-Rule AVP (AVP Code TBD) is of type Grouped and defines a 168 specific condition and action combination. 170 QoS-Rule ::= < AVP Header: XXX > 171 [ QoS-Rule-Precedence ] 173 ; Condition part of a Rule 174 ; ------------------------ 176 [ Classifier ] 177 * [ Time-Of-Day-Condition ] 179 ; Action and Meta-Data 180 ; -------------------- 182 [ QoS-Action ] 184 ; Info about QoS related Actions 185 ; ------------------------------ 187 [ QoS-Semantics ] 188 [ QoS-Profile-Template ] 189 [ QoS-Parameters ] 190 [ Excess-Treatment ] 192 ; Extension Point 193 ; --------------- 194 * [ AVP ] 196 If the QoS-Profile-Template AVP is not included in the Qos-Rule AVP 197 then the default setting is assumed, namely a setting of the 198 Vendor-Id AVP to 0 (for IETF) and the QoS-Profile-Id AVP to zero (0) 199 (for the profile defined in [I-D.ietf-dime-qos-parameters]). Note 200 that the content of the QoS-Parameters are defined in the respective 201 specification defining the QoS parameters. When the Vendor-Id AVP is 202 set to 0 (for IETF) and the QoS-Profile-Id AVP is set to zero (0) 203 then the AVPs included in the QoS-Parameters AVP are the AVPs defined 204 in [I-D.ietf-dime-qos-parameters]. 206 3.3. QoS-Rule-Precedence AVP 208 The QoS-Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and 209 specifies the execution order of the rules expressed in the QoS- 210 Resources AVP. The lower the numerical value of QoS-Rule-Precedence 211 AVP, the higher the rule precedence. Rules with equal precedence MAY 212 be executed in parallel if supported by the Resource Management 213 Function. If the QoS-Rule-Precedence AVP is absent from the QoS-Rule 214 AVP, the rules SHOULD be executed in the order in which they appear 215 in the QoS-Resources AVP. 217 4. Conditions 219 This section describes the condition part of a rule. Two condition 220 types are introduced by this document: packet classification 221 conditions represented by the Classifier AVP and time of day 222 conditions represented by the Time-Of-Day-Condition AVP. 224 If more than one instance of the Time-Of-Day-Condition AVP is present 225 in the QoS-Rule AVP, the current time at QoS rule evaluation MUST be 226 within at least one of the time windows specified in one of the Time- 227 Of-Day-Condition AVPs. 229 When the Time-Of-Day-Condition AVP and Classifier AVP are present in 230 the same QoS-Rule AVP, both the time of day and packet classification 231 conditions MUST match for the QoS specification action to be applied. 233 4.1. Traffic Classifiers 235 Classifiers are used in many applications to specify how to select a 236 subset of data packets for subsequent treatment as indicated in the 237 action part of a rule. For example in a QoS application, if a packet 238 matches a classifier then that packet will be treated in accordance 239 with a QoS specification associated with that classifier. Figure 1 240 shows a typical deployment. 242 +-----------+ 243 +-----------+| 244 +--------+ +-------------+ +------------+|| 245 | | IN | | | ||| 246 | +--------->| +------------->| ||| 247 |Managed | | Classifying | | Unmanaged ||| 248 |Terminal| OUT | Entity | | Terminal ||| 249 | |<---------+ |<-------------+ ||+ 250 | | | | | |+ 251 +--------+ +-------------+ +------------+ 252 ^ 253 | Classifiers 254 | 255 +------+------+ 256 | | 257 | AAA | 258 | | 259 +-------------+ 261 Figure 1: Example of a Classifier Architecture 263 The managed terminal, the terminal for which the classifiers are 264 being specified is located on the left of the Classifying Entity. 265 The unmanaged terminals, the terminals that receive packets from the 266 Managed terminal or send packets to the managed terminal are located 267 to the right side of the Classifying Entity. 269 The Classifying Entity is responsible for classifying packets that 270 are incoming (IN) from the Managed Terminal or packets outgoing (OUT) 271 to the Managed Terminal. 273 A Classifier consists of a group of attributes that specify how to 274 match a packet. Each set of attributes expresses values about 275 aspects of the packet - typically the packet header. Different 276 protocols therefore would use different attributes. 278 In general a Classifier consists of the following: 280 Identifier: 282 The identifier uniquely identifies this classifier and may be used 283 to reference the classifier from another structure. 285 From: 287 Specifies the rule for matching the protocol specific source 288 address(es) part of the packet. 290 To: 292 Specifies the rule for matching the protocol specific destination 293 address(es) part of the packet. 295 Protocol: 297 Specifies the matching protocol of the packet. 299 Direction: 301 Specifies whether the classifier is to apply to packets flowing 302 from the Managed Terminal (IN) or to packets flowing to the 303 Managed Terminal (OUT), or packets flowing in both direction. 305 Options: 307 Attributes or properties associated with each protocol or layer, 308 or various values specific to the header of the protocol or layer. 309 Options allow matching on those values. 311 Each protocol type will have a specific set of attributes that can be 312 used to specify a classifier for that protocol. These attributes 313 will be grouped under a grouped AVP called a Classifier AVP. 315 4.1.1. Classifier AVP 317 The Classifier AVP (AVP Code TBD) is a grouped AVP that consists of a 318 set of attributes that specify how to match a packet. 320 Classifier ::= < AVP Header: XXX > 321 { Classifier-ID } 322 [ Protocol ] 323 [ Direction ] 324 * [ From-Spec ] 325 * [ To-Spec ] 326 * [ Diffserv-Code-Point ] 327 [ Fragmentation-Flag ] 328 * [ IP-Option ] 329 * [ TCP-Option ] 330 [ TCP-Flags ] 331 * [ ICMP-Type ] 332 * [ ETH-Option ] 333 * [ AVP ] 335 4.1.2. Classifier-ID AVP 337 The Classifier-ID AVP (AVP Code TBD) is of type OctetString and 338 uniquely identifies the classifier. Each application will define the 339 uniqueness scope of this identifier, e.g. unique per terminal or 340 globally unique. Exactly one Classifier-ID AVP MUST be contained 341 within a Classifier AVP. 343 4.1.3. Protocol AVP 345 The Protocol AVP (AVP Code TBD) is of type Enumerated and specifies 346 the protocol being matched. The attributes included in the 347 Classifier AVP MUST be consistent with the value of the Protocol AVP. 348 Exactly zero or one Protocol AVP may be contained within a Classifier 349 AVP. If the Protocol AVP is omitted from the Classifier, then 350 comparison of the protocol of the packet is irrelevant. The values 351 for this AVP are managed by IANA under the Protocol Numbers registry 352 as defined in [RFC2780]. 354 4.1.4. Direction AVP 356 The Direction AVP (AVP Code TBD) is of type Enumerated and specifies 357 in which direction to apply the Classifier. The values of the 358 enumeration are: "IN","OUT","BOTH". In the "IN" and "BOTH" 359 directions, the From-Spec refers to the address of the Managed 360 Terminal and the To-Spec refers to the unmanaged terminal. In the 361 "OUT" direction, the From-Spec refers to the Unmanaged Terminal 362 whereas the To-Spec refers to the Managed Terminal. If the Direction 363 AVP is omitted, the Classifier matches packets flowing in both 364 directions. 366 Value | Name and Semantic 367 ------+-------------------------------------------------- 368 0 | IN - The classifier applies to flows from the 369 | Managed Terminal. 370 1 | OUT - The classifier applies to flows to the 371 | Managed Terminal. 372 2 | BOTH - The classifier applies to flows both to 373 | and from the Managed Terminal. 375 4.1.5. From-Spec AVP 377 The From-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the 378 Source Specification used to match the packet. Zero or more of these 379 AVPs may appear in the Classifier. If this AVP is absent from the 380 Classifier then all packets are matched regardless of the source 381 address. If more than one instance of this AVP appears in the 382 Classifier then the source of the packet can match any From-Spec AVP. 383 The contents of this AVP are protocol specific. 385 If one instance (or multiple instances) of the IP address AVP (IP- 386 Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) 387 appear in the From-Spec AVP then the source IP address of the packet 388 MUST match one of the addresses represented by these AVPs. 390 If more that one instance of the layer 2 address AVPs (MAC-Address, 391 MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the 392 From-Spec then the the source layer 2 address of the packet MUST 393 match one of the addresses represented in these AVPs. 395 If more that one instance of the port AVPs (Port, Port-Range) appears 396 in the From-Spec AVP then the source port number MUST match one of 397 the port numbers represented in these AVPs. 399 If the IP address, MAC address and port AVPs appear in the same From- 400 Spec AVP then the source packet MUST match all the specifications, 401 i.e. match the IP address AND MAC address AND port number. 403 From-Spec ::= < AVP Header: XXX > 404 * [ IP-Address ] 405 * [ IP-Address-Range ] 406 * [ IP-Address-Mask ] 407 * [ MAC-Address ] 408 * [ MAC-Address-Mask] 409 * [ EUI64-Address ] 410 * [ EUI64-Address-Mask] 411 * [ Port ] 412 * [ Port-Range ] 413 [ Negated ] 414 [ Use-Assigned-Address ] 415 * [ AVP ] 417 4.1.6. To-Spec AVP 419 The To-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the 420 Destination Specification used to match the packet. Zero or more of 421 these AVPs may appear in the Classifier. If this AVP is absent from 422 the Classifier then all packets are matched regardless of the 423 destination address. If more than one instance of this AVP appears 424 in the Classifier then the destination of the packet can match any 425 To-Spec AVP. The contents of this AVP are protocol specific. 427 If one instance (or multiple instances) of the IP address AVP (IP- 428 Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) 429 appear in the To-Spec AVP then the destination IP address of the 430 packet MUST match one of the addresses represented by these AVPs. 432 If more that one instance of the layer 2 address AVPs (MAC-Address, 433 MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the 434 To-Spec then the the destination layer 2 address of the packet MUST 435 match one of the addresses represented in these AVPs. 437 If more that one instance of the port AVPs (Port, Port-Range) appears 438 in the To-Spec AVP then the destination port number MUST match one of 439 the port numbers represented in these AVPs. 441 If the IP address, MAC address and port AVPs appear in the same To- 442 Spec AVP then the destination packet MUST match all the 443 specifications, i.e. match the IP address AND MAC address AND port 444 number. 446 To-Spec ::= < AVP Header: XXX > 447 * [ IP-Address ] 448 * [ IP-Address-Range ] 449 * [ IP-Address-Mask ] 450 * [ MAC-Address ] 451 * [ MAC-Address-Mask] 452 * [ EUI64-Address ] 453 * [ EUI64-Address-Mask] 454 * [ Port ] 455 * [ Port-Range ] 456 [ Negated ] 457 [ Use-Assigned-Address ] 458 * [ AVP ] 460 4.1.7. Source and Destination AVPs 462 For packet classification the contents of the From-Spec and To-Spec 463 can contain the AVPs listed in the subsections below. 465 4.1.7.1. Negated AVP 467 The Negated AVP (AVP Code TBD) of type Enumerated containing the 468 values of True or False. Exactly zero or one of these AVPs may 469 appear in the From-Spec or To-Spec AVP. 471 When set to True the meaning of the match is inverted. Addresses 472 other than those in the To-Spec and From-Spec are to be matched 473 instead. When set to False, or when the AVP is not included then the 474 address specified To-Spec and From-Spec AVP are to be matched. 476 Note that the negation does not impact the port comparisons. 478 Value | Name 479 ------+-------- 480 0 | False 481 1 | True 483 4.1.7.2. IP-Address AVP 485 The IP-Address AVP (AVP Code TBD) is of type Address and specifies a 486 single IP address (IPv4 or IPv6) address to match. 488 4.1.7.3. IP-Address-Range AVP 490 The IP-Address-Range AVP (AVP Code TBD) is of type Grouped and 491 specifies an inclusive IP address range. 493 IP-Address-Range ::= < AVP Header: XXX > 494 [ IP-Address-Start ] 495 [ IP-Address-End ] 496 * [ AVP ] 498 If the IP-Address-Start AVP is not included then the address range 499 starts from the first valid IP address up to and including the 500 specified IP-Address-End address. 502 If the IP-Address-End AVP is not included then the address range 503 starts at the address specified by the IP-Address-Start AVP and 504 includes all the remaining valid IP addresses. 506 For the IP-Address-Range AVP to be valid, the IP-Address-Start AVP 507 MUST contain a value that is less than that of the IP-Address-End 508 AVP. 510 4.1.7.4. IP-Address-Start AVP 512 The IP-Address-Start AVP (AVP Code TBD) is of type Address and 513 specifies the first IP address (IPv4 or IPv6) address of an IP 514 address range. 516 4.1.7.5. IP-Address-End AVP 518 The IP-Address-End AVP (AVP Code TBD) is of type Address and 519 specifies the last IP address (IPv4 or IPv6) address of an address 520 range. 522 4.1.7.6. IP-Address-Mask AVP 524 The IP-Address-Mask AVP (AVP Code TBD) is of type Grouped and 525 specifies an IP address range using a base IP address and the bit- 526 width of the mask. For example, a range expressed as 192.0.2.0/24 527 will match all IP addresses from 192.0.2.0 up to and including 528 192.0.2.255. The bit-width MUST be valid for the type of IP address. 530 IP-Address-Mask ::= < AVP Header: XXX > 531 { IP-Address } 532 { IP-Bit-Mask-Width } 533 * [ AVP ] 535 4.1.7.7. IP-Mask-Bit-Mask-Width AVP 537 The IP-Bit-Mask-Width AVP (AVP Code TBD) is of type Unsigned32. The 538 value specifies the width of an IP address bit-mask. 540 4.1.7.8. MAC-Address AVP 542 The MAC-Address AVP (AVP Code TBD) is of type OctetString and 543 specifies a single layer 2 address in MAC-48 format. The value is a 544 6 octets encoding of the address as it would appear in the frame 545 header. 547 4.1.7.9. MAC-Address-Mask AVP 549 The MAC-Address-Mask AVP (AVP Code TBD) is of type Grouped and 550 specifies a set of MAC addresses using a bit mask to indicate the 551 bits of the MAC addresses which must fit to the specified MAC address 552 attribute. For example, a MAC-Address-Mask with the MAC-Address as 553 00-10-A4-23-00-00 and with a MAC-Address-Mask-Pattern of FF-FF-FF-FF- 554 00-00 will match all MAC addresses from 00-10-A4-23-00-00 up to and 555 including 00-10-A4-23-FF-FF. 557 MAC-Address-Mask ::= < AVP Header: XXX > 558 { MAC-Address } 559 { MAC-Address-Mask-Pattern } 560 * [ AVP ] 562 4.1.7.10. MAC-Address-Mask-Pattern AVP 564 The MAC-Address-Mask-Pattern AVP (AVP Code TBD) is of type 565 OctetString. The value is a 6 octets specifying the bit positions of 566 a MAC address, that are taken for matching. 568 4.1.7.11. EUI64-Address AVP 570 The EUI64-Address AVP (AVP Code TBD) is of type OctetString and 571 specifies a single layer 2 address in EUI-64 format. The value is a 572 8 octets encoding of the address as it would appear in the frame 573 header. 575 4.1.7.12. EUI64-Address-Mask AVP 577 The EUI64-Address-Mask AVP (AVP Code TBD) is of type Grouped and 578 specifies a set of EUI64 addresses using a bit mask to indicate the 579 bits of the EUI64 addresses which must fit to the specified EUI64 580 address attribute. For example, a EUI64-Address-Mask with the EUI64- 581 Address as 00-10-A4-FF-FE-23-00-00 and with a EUI64-Address-Mask- 582 Pattern of FF-FF-FF-FF-FF-FF-00-00 will match all EUI64 addresses 583 from 00-10-A4-FF-FE-23-00-00 up to and including 00-10-A4-FF-FE-23- 584 FF-FF. 586 EUI64-Address-Mask ::= < AVP Header: XXX > 587 { EUI64-Address } 588 { EUI64-Address-Mask-Pattern } 589 * [ AVP ] 591 4.1.7.13. EUI64-Address-Mask-Pattern AVP 593 The EUI64-Address-Mask-Pattern AVP (AVP Code TBD) is of type 594 OctetString. The value is a 8 octets specifying the bit positions of 595 a EUI64 address, that are taken for matching. 597 4.1.7.14. Port AVP 599 The Port AVP (AVP Code TBD) is of type Integer32 in the range of 0 to 600 65535 and specifies port numbers to match. 602 4.1.7.15. Port-Range AVP 604 The Port-Range AVP (AVP Code TBD) is of type Grouped and specifies an 605 inclusive range of ports. 607 Port-Range ::= < AVP Header: XXX > 608 [ Port-Start ] 609 [ Port-End ] 610 * [ AVP ] 612 If the Port-Start AVP is omitted then port 0 is assumed. If the 613 Port-End AVP is omitted then port 65535 is assumed. 615 4.1.7.16. Port-Start AVP 617 The Port-Start AVP (AVP Code TBD) is of type Integer32 and specifies 618 the first port number of an IP port range. 620 4.1.7.17. Port-End AVP 622 The Port-End AVP (AVP Code TBD) is of type Integer32 and specifies 623 the last port number of an IP port range. 625 4.1.7.18. Use-Assigned-Address AVP 627 In some scenarios, the AAA does not know the IP address assigned to 628 the Managed Terminal at the time that the Classifier is sent to the 629 Classifying Entity. The Use-Assigned-Address AVP (AVP Code TBD) is 630 of type Enumerated containing the values of True or False. When 631 present and set to True, it represents the IP address assigned to the 632 Managed Terminal. 634 Value | Name 635 ------+-------- 636 0 | False 637 1 | True 639 4.1.8. Header Option AVPs 641 The Classifier AVP may contain one or more of the following AVPs to 642 match on the various possible IP, TCP or ICMP header options. 644 4.1.8.1. Diffserv-Code-Point AVP 646 The Diffserv-Code-Point AVP (AVP Code TBD) is of type Enumerated and 647 specifies the Differentiated Services Field Codepoints to match in 648 the IP header. The values are managed by IANA under the 649 Differentiated Services Field Codepoints registry as defined in 650 [RFC2474]. 652 4.1.8.2. Fragmentation-Flag AVP 654 The Fragmentation-Flag AVP (AVP Code TBD) is of type Enumerated and 655 specifies the packet fragmentation flags to match in the IP header. 657 Value | Name and Semantic 658 ------+------------------------------------------------------------ 659 0 | Don't Fragment (DF) 660 1 | More Fragments (MF) 662 4.1.8.3. IP-Option AVP 664 The IP-Option AVP (AVP Code TBD) is of type Grouped and specifies an 665 IP header option that must be matched. 667 IP-Option ::= < AVP Header: XXX > 668 { IP-Option-Type } 669 * [ IP-Option-Value ] 670 [ Negated ] 671 * [ AVP ] 673 If one or more IP-Option-Value AVPs are present, one of the values 674 MUST match the value in the IP header option. If the IP-Option-Value 675 AVP is absent, the option type MUST be present in the IP header but 676 the value is wild carded. 678 The Negated AVP is used in conjunction with the IP-Option-Value AVPs 679 to specify IP header options which do not match specific values. The 680 Negated AVP is used without the IP-Option-Value AVP to specify IP 681 headers which do not contain the option type. 683 4.1.8.4. IP-Option-Type AVP 685 The IP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the 686 values are managed by IANA under the IP Option Numbers registry as 687 defined in [RFC2780]. 689 4.1.8.5. IP-Option-Value AVP 691 The IP-Option-Value AVP (AVP Code TBD) is of type OctetString and 692 contains the option value that must be matched. 694 4.1.8.6. TCP-Option AVP 696 The TCP-Option AVP (AVP Code TBD) is of type Grouped and specifies a 697 TCP header option that must be matched. 699 TCP-Option ::= < AVP Header: XXX > 700 { TCP-Option-Type } 701 * [ TCP-Option-Value ] 702 [ Negated ] 703 * [ AVP ] 705 If one or more TCP-Option-Value AVPs are present, one of the values 706 MUST match the value in the TCP header option. If the TCP-Option- 707 Value AVP is absent, the option type MUST be present in the TCP 708 header but the value is wild carded. 710 The Negated AVP is used in conjunction which the TCP-Option-Value 711 AVPs to specify TCP header options which do not match specific 712 values. The Negated AVP is used without the TCP-Option-Value AVP to 713 specify TCP headers which do not contain the option type. 715 4.1.8.7. TCP-Option-Type AVP 717 The TCP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the 718 values are managed by IANA under the TCP Option Numbers registry as 719 defined in [RFC2780]. 721 4.1.8.8. TCP-Option-Value AVP 723 The TCP-Option-Value AVP (AVP Code TBD) is of type OctetString and 724 contains the option value that must be matched. 726 4.1.8.9. TCP-Flags AVP 728 The TCP-Flags AVP (AVP Code TBD) is of type Grouped and specifies a 729 set of TCP control flags that must be matched. 731 TCP-Flags ::= < AVP Header: XXX > 732 1* { TCP-Flag-Type } 733 [ Negated ] 734 * [ AVP ] 736 If the Negated AVP is not present or present but set to False, the 737 TCP-Flag-Type AVPs specifies which flags MUST be set. If the Negated 738 AVP is set to True, the TCP-Flag-Type AVPs specifies which flags MUST 739 be cleared. 741 4.1.8.10. TCP-Flag-Type AVP 743 The TCP-Flag-Type AVP (AVP Code TBD) is of type Enumerated and 744 specifies a TCP control flag type that must be matched. 746 Value | Name and Semantic 747 ------+------------------------------------------- 748 0 | CWR - Congestion Window Reduced. 749 1 | ECE - ECN-Echo. TCP peer is ECN capable. 750 2 | URG - URGent pointer field is significant. 751 3 | ACK - ACKnowledgment field is significant. 752 4 | PSH - Push function. 753 5 | RST - Reset the connection. 754 6 | SYN - Synchronize sequence numbers. 755 7 | FIN - No more data from sender. 757 4.1.8.11. ICMP-Type 759 The ICMP-Type AVP (AVP Code TBD) is of type Grouped and specifies a 760 ICMP message type that must be matched. 762 ICMP-Type ::= < AVP Header: XXX > 763 { ICMP-Type-Number } 764 * [ ICMP-Code ] 765 [ Negated ] 766 * [ AVP ] 768 If the ICMP-Code AVP is present, the value MUST match that in the 769 ICMP header. If the ICMP-Code AVP is absent, the ICMP type MUST be 770 present in the ICMP header but the code is wild carded. 772 The Negated AVP is used in conjunction with the ICMP-Code AVPs to 773 specify ICMP codes that do not match specific values. The Negated 774 AVP is used without the ICMP-Code AVP to specify ICMP headers which 775 do not contain the ICMP type. As such, the Negated AVP feature 776 applies to ICMP-Code AVP if the ICMP-Code AVP is present. If the 777 ICMP-Code AVP is absent, the Negated AVP feature applies to the ICMP- 778 Type-Number. 780 4.1.8.12. ICMP-Type-Number AVP 782 The ICMP-Type-Number AVP (AVP Code TBD) is of type Enumerated and the 783 values are managed by IANA under the ICMP Type Numbers registry as 784 defined in [RFC2780]. 786 4.1.8.13. ICMP-Code AVP 788 The ICMP-Code AVP (AVP Code TBD) is of type Enumerated and the values 789 are managed by IANA under the ICMP Type Numbers registry as defined 790 in [RFC2780]. 792 4.1.8.14. ETH-Option AVP 794 The ETH-Option AVP (AVP Code TBD) is of type Grouped and specifies 795 Ethernet specific attributes. 797 ETH-Option ::= < AVP Header: XXX > 798 { ETH-Proto-Type } 799 * [ VLAN-ID-Range ] 800 * [ User-Priority-Range ] 801 * [ AVP ] 803 4.1.8.15. ETH-Proto-Type AVP 805 The Eth-Proto-Type AVP (AVP Code TBD) is of type Grouped and 806 specifies the encapsulated protocol type. ETH-Ether-Type and ETH-SAP 807 are mutually exclusive. 809 ETH-Proto-Type ::= < AVP Header: XXX > 810 * [ ETH-Ether-Type ] 811 * [ ETH-SAP ] 812 * [ AVP ] 814 4.1.8.16. ETH-Ether-Type AVP 816 The ETH-Ether-Type AVP (AVP Code TBD) is of type OctetString. The 817 value is a double octet that contains the value of the Ethertype 818 field in the packet to match. This AVP MAY be present in the case of 819 DIX or if SNAP is present at 802.2 but the ETH-SAP AVP MUST NOT be 820 present in this case. 822 4.1.8.17. ETH-SAP AVP 824 The ETH-SAP AVP (AVP Code TBD) is of type OctetString. The value is 825 a double octet representing the 802.2 SAP as specified in 826 [IEEE802.2]. The first octet contains the DSAP and the second the 827 SSAP. 829 4.1.8.18. VLAN-ID-Range AVP 831 The VLAN-ID-Range AVP (AVP Code TBD) is of type Grouped and specifies 832 the VLAN range to match. VLAN identities are either specified by a 833 single VLAN-ID according to [IEEE802.1Q] or by a combination of 834 Customer and Service VLAN-IDs according to [IEEE802.1ad]. 836 The single VLAN-ID is represented by the C-VID-Start and C-VID-End 837 AVPs and the S-VID-Start and S-VID-End AVPs SHALL be ommitted in this 838 case. If the VLAN-ID-Range AVP is omitted from the Classifier, then 839 comparison of the VLAN identity of the packet is irrelevant. 841 VLAN-ID-Range ::= < AVP Header: XXX > 842 [ S-VID-Start ] 843 [ S-VID-End ] 844 [ C-VID-Start ] 845 [ C-VID-End ] 846 * [ AVP ] 848 The following is the list of possible combinations of the S-VID-Start 849 and S-VID-End AVPs and their inference: 851 o If S-VID-Start AVP is present but the S-VID-End AVP is absent, the 852 S-VID-Start AVP value MUST equal the value of the IEEE 802.1ad 853 S-VID bits specified in [IEEE802.1ad] for a successful match. 854 o If S-VID-Start AVP is absent but the S-VID-End AVP is present, the 855 S-VID-End AVP value MUST equal the value of the IEEE 802.1ad S-VID 856 bits for a successful match. 857 o If both S-VID-Start and S-VID-End AVPs are present and their 858 values are equal, the S-VID-Start AVP value MUST equal the value 859 of the IEEE 802.1ad S-VID bits for a successful match. 860 o If both S-VID-Start and S-VID-End AVPs are present and the value 861 of S-VID-End AVP is greater than the value of the S-VID-Start AVP, 862 the value of the IEEE 802.1ad S-VID bits MUST be greater than or 863 equal to the S-VID- Start AVP value and less than or equal to the 864 S-VID-End AVP value for a successful match. If the S-VID-Start 865 and S-VID-End AVPs are specified, then Ethernet packets without 866 IEEE 802.1ad encapsulation MUST NOT match this Classifier. 867 o If the S-VID-Start and S-VID-End AVPs are omitted, then existence 868 of IEEE802.1ad encapsulation or comparison of the IEEE 802.1ad 869 S-VID bits is irrelevant for this Classifier. 871 The following is the list of possible combinations of the C-VID-Start 872 and C-VID-End AVPs and their inference: 874 o If C-VID-Start AVP is present but the C-VID-End AVP is absent, the 875 C-VID-Start AVP value MUST equal the value of the IEEE 802.1ad 876 C-VID bits specified in [IEEE802.1ad] or the IEEE 802.1Q VLAN-ID 877 bits specified in [IEEE802.1Q] for a successful match. 878 o If C-VID-Start AVP is absent but the C-VID-End AVP is present, the 879 C-VID-End AVP value MUST equal the value of the IEEE 802.1ad C-VID 880 bits or the IEEE 802.1Q VLAN-ID bits for a successful match. 881 o If both C-VID-Start and C-VID-End AVPs are present and their 882 values are equal, the C-VID-Start AVP value MUST equal the value 883 of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits for 884 a successful match. 886 o If both C-VID-Start and C-VID-End AVPs are present and the value 887 of C-VID-End AVP is greater than the value of the C-VID-Start AVP, 888 the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q 889 VLAN-ID bits MUST be greater than or equal to the C-VID-Start AVP 890 value and less than or equal to the C-VID-End AVP value for a 891 successful match. If the C-VID-Start and C-VID-End AVPs are 892 specified, then Ethernet packets without IEEE 802.1ad or IEEE 893 802.1Q encapsulation MUST NOT match this Classifier. 894 o If the C-VID-Start and C-VID-End AVPs are omitted, the comparison 895 of the IEEE 802.1ad C-VID bits or IEEE 802.1Q VLAN-ID bits for 896 this Classifier is irrelevant. 898 4.1.8.19. S-VID-Start AVP 900 The S-VID-Start AVP (AVP Code TBD) is of type Unsigned32. The value 901 MUST be in the range from 0 to 4095. The value of this AVP specifies 902 the start value of the range of S-VID VLAN-IDs to be matched. 904 4.1.8.20. S-VID-End AVP 906 The S-VID-End AVP (AVP Code TBD) is of type Unsigned32. The value 907 MUST be in the range from 0 to 4095. The value of this AVP specifies 908 the end value of the range of S-VID VLAN-IDs to be matched. 910 4.1.8.21. C-VID-Start AVP 912 The C-VID-Start AVP (AVP Code TBD) is of type Unsigned32. The value 913 MUST be in the range from 0 to 4095. The value of this AVP specifies 914 the start value of the range of C-VID VLAN-IDs to be matched. 916 4.1.8.22. C-VID-End AVP 918 The C-VID-End 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 end value of the range of C-VID VLAN-IDs to be matched. 922 4.1.8.23. User-Priority-Range AVP 924 The User-Priority-Range AVP (AVP Code TBD) is of type Grouped and 925 specifies an inclusive range to match the user_priority parameter 926 specified in [IEEE802.1D]. An Ethernet packet containing the 927 user_priority parameter matches this Classifier if the value is 928 greater than or equal to Low-User-Priority and less than or equal to 929 High-User-Priority. If this AVP is omitted, then comparison of the 930 IEEE 802.1D user_priority parameter for this Classifier is 931 irrelevant. 933 User-Priority-Range ::= < AVP Header: XXX > 934 * [ Low-User-Priority ] 935 * [ High-User-Priority ] 936 * [ AVP ] 938 4.1.8.24. Low-User-Priority AVP 940 The Low-User-Priority AVP (AVP Code TBD) is of type Unsigned32. The 941 value MUST be in the range from 0 to 7. 943 4.1.8.25. High-User-Priority AVP 945 The High-User-Priority AVP (AVP Code TBD) is of type Unsigned32. The 946 value MUST be in the range from 0 to 7. 948 4.2. Time Of Day AVPs 950 In many QoS applications, the QoS specification applied to the 951 traffic flow is conditional upon the time of day when the flow was 952 observed. The following sections define AVPs that can be used to 953 express one or more time windows which determine when a QoS 954 specification is applicable to a traffic flow. 956 4.2.1. Time-Of-Day-Condition AVP 958 The Time-Of-Day-Condition AVP (AVP Code TBD) is of type Grouped and 959 specifies one or more time windows. 961 Time-Of-Day-Condition ::= < AVP Header: XXX > 962 [ Time-Of-Day-Start ] 963 [ Time-Of-Day-End ] 964 [ Day-Of-Week-Mask ] 965 [ Day-Of-Month-Mask ] 966 [ Month-Of-Year-Mask ] 967 [ Absolute-Start-Time ] 968 [ Absolute-End-Time ] 969 [ Timezone-Flag ] 970 * [ AVP ] 972 For example, a time window for 9am to 5pm (local time) from Monday to 973 Friday would be expressed as: 975 Time-Of-Day-Condition = { 976 Time-Of-Day-Start = 32400; 977 Time-Of-Day-End = 61200; 978 Day-Of-Week-Mask = 979 ( MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY ); 980 Timezone-Flag = LOCAL; 981 } 983 4.2.2. Time-Of-Day-Start AVP 985 The Time-Of-Day-Start AVP (AVP Code TBD) is of type Unsigned32. The 986 value MUST be in the range from 0 to 86400. The value of this AVP 987 specifies the start of an inclusive time window expressed as the 988 offset in seconds from midnight. If this AVP is absent from the 989 Time-Of-Day-Condition AVP, the time window starts at midnight. 991 4.2.3. Time-Of-Day-End AVP 993 The Time-Of-Day-End AVP (AVP Code TBD) is of type Unsigned32. The 994 value MUST be in the range from 1 to 86400. The value of this AVP 995 specifies the end of an inclusive time window expressed as the offset 996 in seconds from midnight. If this AVP is absent from the Time-Of- 997 Day-Condition AVP, the time window ends one second before midnight. 999 4.2.4. Day-Of-Week-Mask AVP 1001 The Day-Of-Week-Mask AVP (AVP Code TBD) is of type Unsigned32. The 1002 value is a bitmask which specifies the day of the week for the time 1003 window to match. This document specifies the following bits: 1005 Bit | Name 1006 ------+------------ 1007 0 | SUNDAY 1008 1 | MONDAY 1009 2 | TUESDAY 1010 3 | WEDNESDAY 1011 4 | THURSDAY 1012 5 | FRIDAY 1013 6 | SATURDAY 1015 The bit MUST be set for the time window to match on the corresponding 1016 day of the week. Bit 0 is the most significant bit and unused bits 1017 MUST be cleared. If this AVP is absent from the Time-Of-Day- 1018 Condition AVP, the time windows match on all days of the week. 1020 4.2.5. Day-Of-Month-Mask AVP 1022 The Day-Of-Week-Month AVP (AVP Code TBD) is of type Unsigned32. The 1023 value MUST be in the range from 0 to 2147483647. The value is a 1024 bitmask which specifies the days of the month where bit 0 represents 1025 the first day of the month through to bit 30 which represents the 1026 last day of the month. The bit MUST be set for the time window to 1027 match on the corresponding day of the month. Bit 0 is the most 1028 significant bit and unused bits MUST be cleared. If this AVP is 1029 absent from the Time-Of-Day-Condition AVP, the time windows match on 1030 all days of the month. 1032 4.2.6. Month-Of-Year-Mask AVP 1034 The Month-Of-Year-Month AVP (AVP Code TBD) is of type Unsigned32. 1035 The value is a bitmask which specifies the months of the year for the 1036 time window to match. This document specifies the following bits: 1038 Bit | Name 1039 ------+----------- 1040 0 | JANUARY 1041 1 | FEBRUARY 1042 2 | MARCH 1043 3 | APRIL 1044 4 | MAY 1045 5 | JUNE 1046 6 | JULY 1047 7 | AUGUST 1048 8 | SEPTEMBER 1049 9 | OCTOBER 1050 10 | NOVEMBER 1051 11 | DECEMBER 1053 The bit MUST be set for the time window to match on the corresponding 1054 month of the year. Bit 0 is the most significant bit and unused bits 1055 MUST be cleared. If this AVP is absent from the Time-Of-Day- 1056 Condition AVP, the time windows match during all months of the year. 1058 4.2.7. Absolute-Start-Time AVP 1060 The Absolute-Start-Time AVP (AVP Code TBD) is of type Time. The 1061 value of this AVP specifies the time in seconds since January 1, 1062 1900, 00:00 UTC when the time window starts. If this AVP is absent 1063 from the Time-Of-Day-Condition AVP, the time window starts on January 1064 1, 1900, 00:00 UTC. 1066 4.2.8. Absolute-End-Time AVP 1068 The Time-Of-Day-End AVP (AVP Code TBD) is of type Time. The value of 1069 this AVP specifies the time in seconds since January 1, 1900, 00:00 1070 UTC when the time window ends. If this AVP is absent from the Time- 1071 Of-Day-Condition AVP, the time window is open-ended. 1073 4.2.9. Timezone-Flag AVP 1075 The Timezone-Flag AVP (AVP Code TBD) is of type Enumerated and 1076 indicates whether the time windows are specified in UTC, local time 1077 at the managed terminal or as an offset from UTC. If this AVP is 1078 absent from the Time-Of-Day-Condition AVP, the time windows are in 1079 UTC. 1081 This document defines the following values: 1083 Value | Name and Semantic 1084 ------+-------------------------------------------------- 1085 0 | UTC - The time windows are expressed in UTC. 1086 1 | LOCAL - The time windows are expressed in local 1087 | time at the Managed Terminal. 1088 2 | OFFSET - The time windows are expressed as an 1089 | offset from UTC (see Timezone-Offset AVP). 1091 4.2.10. Timezone-Offset AVP 1093 The Timezone-Offset AVP (AVP Code TBD) is of type Integer32. The 1094 value of this AVP MUST be in the range from -43200 to 43200. It 1095 specifies the offset in seconds from UTC that was used to express 1096 Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month- 1097 Mask and Month-Of-Year-Mask AVPs. This AVP MUST be present if the 1098 Timezone-Flag AVP is set to OFFSET. 1100 5. Actions 1102 This section illustrates the actions associated with a rule. This 1103 document only defines QoS specific actions but further actions can be 1104 specified as extensions. 1106 5.1. QoS-Action AVP 1108 The QoS-Action AVP (AVP Code TBD) is of type Enumerated and lists the 1109 actions that are associated with the condition part of a rule. The 1110 following actions are defined in this document: 1112 0: drop 1113 1: shape 1114 2: mark 1116 drop: 1118 All traffic that is met by the condition part of a rule MUST be 1119 dropped. This action implements firewalling functionality. 1121 shape: 1123 [RFC2475] describes shaping as "the process of delaying packets 1124 within a traffic stream to cause it to conform to some defined 1125 traffic profile". When the action is set to 'shape', it is 1126 expected that the QoS-Parameters AVP carries QoS information to 1127 indicate how to shape the traffic indicated in the condition part 1128 of the rule. 1130 mark: 1132 [RFC2475] describes marking as "the process of setting the DS 1133 codepoint in a packet based on defined rules". When the action is 1134 set to 'mark', it is expected that the QoS-Parameters AVP carries 1135 information about the DiffServ marking. 1137 Further action values can be registered, as described in 1138 Section 10.3. 1140 [RFC2475] also describes an action called "policing" as "the process 1141 of discarding packets (by a dropper) within a traffic stream in 1142 accordance with the state of a corresponding meter enforcing a 1143 traffic profile". This behavior in modeled in the QoS-Rule through 1144 the inclusion of the Excess-Treatment AVP containing a QoS-Action AVP 1145 set to "drop". 1147 5.2. QoS-Profile-Id AVP 1149 The QoS-Profile-Id AVP (AVP Code TBD) is of type Unsigned32 and 1150 contains a QoS profile template identifier. An initial QoS profile 1151 template is defined with value of 0 and can be found in 1152 [I-D.ietf-dime-qos-parameters]. The registry for the QoS profile 1153 templates is created with the same document. 1155 5.3. QoS-Profile-Template AVP 1157 The QoS-Profile-Template AVP (AVP Code TBD) is of type Grouped and 1158 defines the namespace of the QoS profile (indicated in the Vendor-ID 1159 AVP) followed by the specific value for the profile. 1161 The Vendor-Id AVP contains a 32 bit IANA Private Enterprise Number 1162 (PEN) and the QoS-Profile-Id AVP contains the template identifier 1163 assigned by the vendor. The vendor identifier of zero (0) is used 1164 for the IETF. 1166 QoS-Profile-Template ::= < AVP Header: XXX > 1167 { Vendor-Id } 1168 { QoS-Profile-Id } 1169 * [ AVP ] 1171 5.4. QoS-Semantics 1173 The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and 1174 provides the semantics for the QoS-Profile-Template and QoS- 1175 Parameters AVPs in the QoS-Rule AVP. 1177 This document defines the following values: 1179 (0): QoS-Desired 1180 (1): QoS-Available 1181 (2): QoS-Reserved 1182 (3): Minimum-QoS 1183 (4): QoS-Authorized 1185 The semantic of the QoS parameters depend on the information provided 1186 in the list above. The semantics of the different values are as 1187 follows: 1189 Object Type Direction Semantic 1190 --------------------------------------------------------------------- 1191 QoS-Desired C->S Please authorize the indicated QoS 1192 QoS-Desired C<-S NA 1193 QoS-Available C->S Admission Control at interface indicates 1194 that this QoS is available. (note 1) 1195 QoS-Available C<-S Indicated QoS is available. (note 2) 1196 QoS-Reserved C->S Used for reporting during accounting. 1197 QoS-Reserved C<-S NA 1198 Minimum-QoS C->S Indicates that the client is not 1199 interested in authorizing QoS that is 1200 lower than Min. QoS. 1201 Minimum-QoS C<-S The client must not provide QoS 1202 guarantees lower than Min. QoS. 1203 QoS-Authorized C->S NA 1204 QoS-Authorized C<-S Indicated QoS authorized 1206 Legend: 1208 C: Diameter client 1209 S: Diameter server 1210 NA: Not applicable to this document; 1211 no semantic defined in this specification 1213 Notes: 1215 (1) QoS-Available is only useful in relationship with QoS-Desired 1216 (and optionally with Minimum-QoS). 1217 (2) QoS-Available is only useful when the AAA server performs 1218 admission control and knows about the resources in the network. 1220 5.5. QoS-Parameters AVP 1222 The QoS-Parameters AVP (AVP Code TBD) is of type grouped and contains 1223 Quality of Service parameters. These parameters are defined in 1224 separate documents and depend on the indicated QoS profile template 1225 of the QoS-Profile-Template AVP. For an initial QoS parameter 1226 specification see [I-D.ietf-dime-qos-parameters]. 1228 QoS-Parameters ::= < AVP Header: XXX > 1229 * [ AVP ] 1231 5.6. Excess-Treatment AVP 1233 The Excess-Treatment AVP (AVP Code TBD) is of type grouped and 1234 indicates how out-of-profile traffic, i.e. traffic not covered by the 1235 original QoS-Profile-Template and QoS-Parameters AVPs, is treated. 1237 The additional QoS-Action, QoS-Profile-Template and QoS-Parameters 1238 AVPs carried inside the Excess-Treatment AVP provide information 1239 about the QoS treatment of the excess traffic. In case the Excess- 1240 Treatment AVP is absent then the treatment of the out-of-profile 1241 traffic is left to the discretion of the node performing QoS 1242 treatment. 1244 Excess-Treatment ::= < AVP Header: XXX > 1245 { QoS-Action } 1246 [ QoS-Profile-Template ] 1247 [ QoS-Parameters ] 1248 * [ AVP ] 1250 6. QoS Capability Indication 1252 The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains 1253 a list of supported Quality of Service profile templates (and 1254 therefore the support of the respective parameter AVPs). 1256 The QoS-Capability AVP may be used for a simple announcement of the 1257 QoS capabilities and QoS profiles supported by a peer. It may also 1258 be used to negotiate a mutually supported set of QoS capabilities and 1259 QoS profiles between two peers. In such a case, handling of failed 1260 negotiations is application and/or deployment specific. 1262 QoS-Capability ::= < AVP Header: XXX > 1263 1*{ QoS-Profile-Template } 1264 * [ AVP ] 1266 The QoS-Profile-Template AVP is defined in Section 5.3. 1268 7. Examples 1270 This section shows a number of signaling flows where QoS negotiation 1271 and authorization is part of the conventional NASREQ, EAP or Credit 1272 Control applications message exchanges. The signalling flows for the 1273 Diameter QoS Application are described in 1274 [I-D.ietf-dime-diameter-qos]. 1276 7.1. Diameter EAP with QoS Information 1278 Figure 2 shows a simple signaling flow where a NAS (Diameter Client) 1279 announces its QoS awareness and capabilities included into the DER 1280 message and as part of the access authentication procedure. Upon 1281 completion of the EAP exchange, the Diameter Server provides a pre- 1282 provisioned QoS profile with the QoS-Semantics in the QoS-Rule AVP 1283 set to "QoS-Authorized", to the NAS in the final DEA message. 1285 End Diameter Diameter 1286 Host Client Server 1287 | | | 1288 | (initiate EAP) | | 1289 |<----------------------------->| | 1290 | | Diameter-EAP-Request | 1291 | | EAP-Payload(EAP Start) | 1292 | | QoS-Capability | 1293 | |------------------------------->| 1294 | | | 1295 | | Diameter-EAP-Answer | 1296 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 1297 | | EAP-Payload(EAP Request #1) | 1298 | |<-------------------------------| 1299 | EAP Request(Identity) | | 1300 |<------------------------------| | 1301 : : : 1302 : <<>> : 1303 : : : 1304 | | | 1305 | EAP Response #N | | 1306 |------------------------------>| | 1307 | | Diameter-EAP-Request | 1308 | | EAP-Payload(EAP Response #N) | 1309 | |------------------------------->| 1310 | | | 1311 | | Diameter-EAP-Answer | 1312 | | Result-Code=DIAMETER_SUCCESS | 1313 | | EAP-Payload(EAP Success) | 1314 | | (authorization AVPs) | 1315 | | QoS-Resources(QoS-Authorized) | 1316 | |<-------------------------------| 1317 | | | 1318 | EAP Success | | 1319 |<------------------------------| | 1320 | | | 1322 Figure 2: Example of a Diameter EAP enhanced with QoS Information 1324 7.2. Diameter NASREQ with QoS Information 1326 Figure 3 shows a similar pre-provisioned QoS signaling as in Figure 2 1327 but using the NASREQ application instead of EAP application. 1329 End Diameter 1330 Host NAS Server 1331 | | | 1332 | Start Network | | 1333 | Attachment | | 1334 |<---------------->| | 1335 | | | 1336 | |AA-Request | 1337 | |NASREQ-Payload | 1338 | |QoS-Capability | 1339 | +----------------------------->| 1340 | | | 1341 | | AA-Answer| 1342 | Result-Code=DIAMETER_MULTI_ROUND_AUTH| 1343 | NASREQ-Payload(NASREQ Request #1)| 1344 | |<-----------------------------+ 1345 | | | 1346 | Request | | 1347 |<-----------------+ | 1348 | | | 1349 : : : 1350 : <<>> : 1351 : : : 1352 | Response #N | | 1353 +----------------->| | 1354 | | | 1355 | |AA-Request | 1356 | |NASREQ-Payload ( Response #N )| 1357 | +----------------------------->| 1358 | | | 1359 | | AA-Answer| 1360 | | Result-Code=DIAMETER_SUCCESS| 1361 | | (authorization AVPs)| 1362 | | QoS-Resources(QoS-Authorized)| 1363 | |<-----------------------------+ 1364 | | | 1365 | Success | | 1366 |<-----------------+ | 1367 | | | 1369 Figure 3: Example of a Diameter NASREQ enhanced with QoS Information 1371 7.3. QoS Authorization 1373 Figure 4 shows an example of authorization only QoS signaling as part 1374 of the NASREQ message exchange. The NAS provides the Diameter server 1375 with the "QoS-Desired" QoS-Semantics AVP included in the QoS- 1376 Resources AVP. The Diameter server then either authorizes the 1377 indicated QoS or rejects the request and informs the NAS about the 1378 result. In this scenario the NAS does not need to include the QoS- 1379 Capability AVP in the AAR message as the QoS-Resources AVP implicitly 1380 does the same and also the NAS is authorizing a specific QoS profile, 1381 not a pre-provisioned one. 1383 End Diameter 1384 Host NAS Server 1385 | | | 1386 | | | 1387 | QoS Request | | 1388 +----------------->| | 1389 | | | 1390 | |AA-Request | 1391 | |Auth-Request-Type=AUTHORIZE_ONLY 1392 | |NASREQ-Payload | 1393 | |QoS-Resources(QoS-Desired) | 1394 | +----------------------------->| 1395 | | | 1396 | | AA-Answer| 1397 | | NASREQ-Payload(Success)| 1398 | | QoS-Resources(QoS-Authorized)| 1399 | |<-----------------------------+ 1400 | Accept | | 1401 |<-----------------+ | 1402 | | | 1403 | | | 1404 | | | 1406 Figure 4: Example of an Authorization-Only Message Flow 1408 7.4. Diameter Server Initiated Re-authorization of QoS 1410 Figure 5 shows a message exchange for a Diameter server initiated QoS 1411 re-authorization procedure. The Diameter server sends the NAS a RAR 1412 message requesting re-authorization for an existing session and the 1413 NAS acknowledges it with a RAA message. The NAS is aware of its 1414 existing QoS profile and information for the ongoing session that the 1415 Diameter server requested for re-authorization. Thus, the NAS must 1416 initiate re-authorization of the existing QoS profile. The re- 1417 authorization procedure is the same as in Figure 4. 1419 End Diameter 1420 Host NAS Server 1421 | | | 1422 | | | 1423 : : : 1424 : <<>> : 1425 : : : 1426 | | | 1427 | | RA-Request | 1428 | |<-----------------------------+ 1429 | | | 1430 | |RA-Answer | 1431 | |Result-Code=DIAMETER_SUCCESS | 1432 | +----------------------------->| 1433 | | | 1434 | | | 1435 | |AA-Request | 1436 | |NASREQ-Payload | 1437 | |Auth-Request-Type=AUTHORIZE_ONLY 1438 | |QoS-Resources(QoS-Desired) | 1439 | +----------------------------->| 1440 | | | 1441 | | AA-Answer| 1442 | | Result-Code=DIAMETER_SUCCESS| 1443 | | (authorization AVPs)| 1444 | | QoS-Resources(QoS-Authorized)| 1445 | |<-----------------------------+ 1446 | | | 1448 Figure 5: Example of a Server-initiated Re-Authorization Procedure 1450 7.5. Diameter Credit Control with QoS Information 1452 In this case the User is charged as soon as the Service Element (CC 1453 client) receives the service request. In this case the client uses 1454 the "QoS-Desired" QoS-Semantics parameter in the QoS-Resources AVP 1455 that it sends to the Accounitng server. The server responds with a 1456 "QoS-Available" QoS-Semantics parameter in the QoS-Resources AVP 1457 Service Element 1458 End User (CC Client) B CC Server 1459 | | | | 1460 |(1) Service Request | | | 1461 |-------------------->| | | 1462 | |(2) CCR (event, DIRECT_DEBITING,| 1463 | | QoS-Resources(QoS-desired)) | 1464 | |-------------------------------->| 1465 | |(3) CCA (Granted-Units, QoS- | 1466 | | Resources(QoS-Authorized)) | 1467 | |<--------------------------------| 1468 |(4) Service Delivery | | | 1469 |<--------------------| | | 1470 |(5) Begin service | | | 1471 |<------------------------------------>| | 1472 | | | | 1473 . . . . 1474 . . . . 1476 Figure 6: Example for a One-Time Diameter Credit Control Charging 1477 Event 1479 7.6. Classifier Examples 1481 Example: Classify all packets from hosts on subnet 192.0.2.0/24 to 1482 ports 80, 8090 or 443 on web servers 192.0.2.123, 192.0.2.124, 1483 192.0.2.125. 1485 Classifier = { 1486 Classifier-Id = "web_svr_example"; 1487 Protocol = TCP; 1488 Direction = OUT; 1489 From-Spec = { 1490 IP-Address-Mask = { 1491 IP-Address = 192.0.2.0; 1492 IP-Bit-Mask-Width = 24; 1493 } 1494 } 1495 To-Spec = { 1496 IP-Address = 192.0.2.123; 1497 IP-Address = 192.0.2.124; 1498 IP-Address = 192.0.2.125; 1499 Port = 80; 1500 Port = 8080; 1501 Port = 443; 1502 } 1503 } 1504 Example: Any SIP signalling traffic from a device with a MAC address 1505 of 01:23:45:67:89:ab to servers with IP addresses in the range 1506 192.0.2.90 to 192.0.2.190. 1508 Classifier = { 1509 Classifier-Id = "web_svr_example"; 1510 Protocol = UDP; 1511 Direction = OUT; 1512 From-Spec = { 1513 MAC-Address = 01:23:45:67:89:ab; 1514 } 1515 To-Spec = { 1516 IP-Address-Range = { 1517 IP-Address-Start = 192.0.2.90; 1518 IP-Address-End = 192.0.2.190; 1519 } 1520 Port = 5060; 1521 Port = 3478; 1522 Port-Range = { 1523 Port-Start = 16348; 1524 Port-End = 32768; 1525 } 1526 } 1527 } 1529 7.7. QoS Examples 1531 The following high level description aims to illustrate the 1532 interworking between the Diameter QoS AVPs defined in this document 1533 and the QoS parameters defined in [I-D.ietf-dime-qos-parameters]. 1535 Consider the following example where a rule should be installed that 1536 limits traffic to 1 Mbit/sec and where out-of-profile traffic shall 1537 be dropped.The Classifers are ignored in this example. 1539 This would require the QoS-Action AVP to be set to 'shape' and the 1540 QoS-Parameters AVP carries the Bandwidth AVP indicating the 1 Mbit/ 1541 sec limit. The QoS-Action carried inside the Excess-Treatment AVP 1542 would be set to 'drop'. 1544 In a second, more complex scenario, we consider traffic marking with 1545 DiffServ. In-profile traffic (of 5 Mbits/sec in our example) shall 1546 be associated with a particular PHB-Class "X". Out-of-profile 1547 traffic shall belong to a different PHB-Class, in our example "Y". 1549 This configuration would require the QoS-Action AVP to be set to 1550 'mark'. The QoS-Parameters AVPs for the traffic conforming of the 1551 profile contains two AVPs, namely the TMOD-1 AVP and the PHB-Class 1552 AVP. The TMOD-1 AVP describes the traffic characteristics, namely 5 1553 Mbit/sec, and the PHB-Class AVP is set to class "X". Then, the 1554 Excess-Treatment AVP has to be included with the QoS-Action AVP set 1555 to 'mark' and the QoS-Parameters AVP to carry another PHB-Class AVP 1556 indicating PHB-Class AVP setting to class "Y". 1558 8. Acknowledgments 1560 We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, 1561 Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Tolga 1562 Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina Tsou, 1563 Pete McCann, Georgios Karagiannis, Elwyn Davies, Max Riegel and Yong 1564 Li for their comments. We thank Victor Fajardo for his job as PROTO 1565 document shepherd. 1567 9. Contributors 1569 Max Riegel contributed the VLAN sections. 1571 10. IANA Considerations 1573 10.1. AVP Codes 1575 IANA is requested to allocate AVP codes for the following AVPs that 1576 are defined in this document. 1578 +--------------------------------------------------------------------+ 1579 | AVP Section | 1580 | Attribute Name Code Defined Data Type | 1581 +--------------------------------------------------------------------+ 1582 |QoS-Resources TBD 3.1 Grouped | 1583 |QoS-Rule TBD 3.2 Grouped | 1584 |QoS-Rule-Precedence TBD 3.3 Unsigned32 | 1585 |Classifier TBD 4.1.1 Grouped | 1586 |Classifier-ID TBD 4.1.2 OctetString | 1587 |Protocol TBD 4.1.3 Enumerated | 1588 |Direction TBD 4.1.4 Enumerated | 1589 |From-Spec TBD 4.1.5 Grouped | 1590 |To-Spec TBD 4.1.6 Grouped | 1591 |Negated TBD 4.1.7.1 Enumerated | 1592 |IP-Address TBD 4.1.7.2 Address | 1593 |IP-Address-Range TBD 4.1.7.3 Grouped | 1594 |IP-Address-Start TBD 4.1.7.4 Address | 1595 |IP-Address-End TBD 4.1.7.5 Address | 1596 |IP-Address-Mask TBD 4.1.7.6 Grouped | 1597 |IP-Mask-Bit-Mask-Width TBD 4.1.7.7 Unsigned32 | 1598 |MAC-Address TBD 4.1.7.8 OctetString | 1599 |MAC-Address-Mask TBD 4.1.7.9 Grouped | 1600 |MAC-Address-Mask-Pattern TBD 4.1.7.10 OctetString | 1601 |EUI64-Address TBD 4.1.7.11 OctetString | 1602 |EUI64-Address-Mask TBD 4.1.7.12 Grouped | 1603 |EUI64-Address-Mask-Pattern TBD 4.1.7.13 OctetString | 1604 |Port TBD 4.1.7.14 Integer32 | 1605 |Port-Range TBD 4.1.7.15 Grouped | 1606 |Port-Start TBD 4.1.7.16 Integer32 | 1607 |Port-End TBD 4.1.7.17 Integer32 | 1608 |Use-Assigned-Address TBD 4.1.7.18 Enumerated | 1609 |Diffserv-Code-Point TBD 4.1.8.1 Enumerated | 1610 |Fragmentation-Flag TBD 4.1.8.2 Enumerated | 1611 |IP-Option TBD 4.1.8.3 Grouped | 1612 |IP-Option-Type TBD 4.1.8.4 Enumerated | 1613 |IP-Option-Value TBD 4.1.8.5 OctetString | 1614 |TCP-Option TBD 4.1.8.6 Grouped | 1615 |TCP-Option-Type TBD 4.1.8.7 Enumerated | 1616 |TCP-Option-Value TBD 4.1.8.8 OctetString | 1617 |TCP-Flags TBD 4.1.8.9 Grouped | 1618 |TCP-Flag-Type TBD 4.1.8.10 Enumerated | 1619 |ICMP-Type TBD 4.1.8.11 Grouped | 1620 |ICMP-Type-Number TBD 4.1.8.12 Enumerated | 1621 |ICMP-Code TBD 4.1.8.13 Enumerated | 1622 |ETH-Option TBD 4.1.8.14 Grouped | 1623 |ETH-Proto-Type TBD 4.1.8.15 Grouped | 1624 |ETH-Ether-Type TBD 4.1.8.16 OctetString | 1625 |ETH-SAP TBD 4.1.8.17 OctetString | 1626 |VLAN-ID-Range TBD 4.1.8.18 Grouped | 1627 |S-VID-Start TBD 4.1.8.19 Unsigned32 | 1628 |S-VID-End TBD 4.1.8.20 Unsigned32 | 1629 |C-VID-Start TBD 4.1.8.21 Unsigned32 | 1630 |C-VID-End TBD 4.1.8.22 Unsigned32 | 1631 |User-Priority-Range TBD 4.1.8.23 Grouped | 1632 |Low-User-Priority TBD 4.1.8.24 Unsigned32 | 1633 |High-User-Priority TBD 4.1.8.25 Unsigned32 | 1634 |Time-Of-Day-Condition TBD 4.2.1 Grouped | 1635 |Time-Of-Day-Start TBD 4.2.2 Unsigned32 | 1636 |Time-Of-Day-End TBD 4.2.3 Unsigned32 | 1637 |Day-Of-Week-Mask TBD 4.2.4 Unsigned32 | 1638 |Day-Of-Month-Mask TBD 4.2.5 Unsigned32 | 1639 |Month-Of-Year-Mask TBD 4.2.6 Unsigned32 | 1640 |Absolute-Start-Time TBD 4.2.7 Time | 1641 |Absolute-End-Time TBD 4.2.8 Time | 1642 |Timezone-Flag TBD 4.2.9 Enumerated | 1643 |Timezone-Offset TBD 4.2.10 Integer32 | 1644 |QoS-Action TBD 5.1 Grouped | 1645 |QoS-Profile-Id TBD 5.2 Unsigned32 | 1646 |QoS-Profile-Template TBD 5.3 Grouped | 1647 |QoS-Semantics TBD 5.4 Enumerated | 1648 |QoS-Parameters TBD 5.5 Grouped | 1649 |Excess-Treatment TBD 5.6 Grouped | 1650 |QoS-Capability TBD 6 Grouped | 1651 +--------------------------------------------------------------------+ 1653 10.2. QoS-Semantics IANA Registry 1655 IANA is also requested to allocate a registry for the QoS-Semantics 1656 AVP. The following values are allocated by this specification. 1658 (0): QoS-Desired 1659 (1): QoS-Available 1660 (2): QoS-Reserved 1661 (3): Minimum-QoS 1662 (4): QoS-Authorized 1664 The definition of new values is subject to the Specification Required 1665 policy [RFC5226]. 1667 10.3. Action 1669 IANA is also requested to allocate a registry for the QoS-Action AVP. 1670 The following values are allocated by this specification: 1672 0: drop 1673 1: shape 1674 2: mark 1676 The definition of new values is subject to the Specification Required 1677 policy [RFC5226]. 1679 11. Security Considerations 1681 This document describes the extension of Diameter for conveying 1682 Quality of Service information. The security considerations of the 1683 Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. 1684 Use of the AVPs defined in this document MUST take into consideration 1685 the security issues and requirements of the Diameter Base protocol. 1687 12. References 1688 12.1. Normative References 1690 [IEEE802.1D] 1691 IEEE, "IEEE Standard for Local and metropolitan area 1692 networks, Media Access Control (MAC) Bridges", 2004. 1694 [IEEE802.1Q] 1695 IEEE, "IEEE Standard for Local and metropolitan area 1696 networks, Virtual Bridged Local Area Networks", 2005. 1698 [IEEE802.1ad] 1699 IEEE, "IEEE Standard for Local and metropolitan area 1700 networks, Virtual Bridged Local Area Networks, Amendment 1701 4: Provider Bridges", 2005. 1703 [IEEE802.2] 1704 IEEE, "IEEE Standard for Information technology, 1705 Telecommunications and information exchange between 1706 systems, Local and metropolitan area networks, Specific 1707 requirements, Part 2: Logical Link Control", 1998. 1709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1710 Requirement Levels", BCP 14, RFC 2119, March 1997. 1712 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1713 "Definition of the Differentiated Services Field (DS 1714 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1715 December 1998. 1717 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1718 Values In the Internet Protocol and Related Headers", 1719 BCP 37, RFC 2780, March 2000. 1721 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1722 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1723 May 2008. 1725 12.2. Informative References 1727 [I-D.ietf-dime-diameter-qos] 1728 Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 1729 and G. Zorn, "Diameter Quality of Service Application", 1730 draft-ietf-dime-diameter-qos-08 (work in progress), 1731 May 2009. 1733 [I-D.ietf-dime-qos-parameters] 1734 Korhonen, J., Tschofenig, H., and E. Davies, "Quality of 1735 Service Parameters for Usage with Diameter", 1736 draft-ietf-dime-qos-parameters-11 (work in progress), 1737 May 2009. 1739 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1740 and W. Weiss, "An Architecture for Differentiated 1741 Services", RFC 2475, December 1998. 1743 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1744 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1746 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1747 "Diameter Network Access Server Application", RFC 4005, 1748 August 2005. 1750 Authors' Addresses 1752 Jouni Korhonen 1753 Nokia Siemens Networks 1754 Linnoitustie 6 1755 Espoo 02600 1756 Finland 1758 Email: jouni.korhonen@nsn.com 1760 Hannes Tschofenig 1761 Nokia Siemens Networks 1762 Linnoitustie 6 1763 Espoo 02600 1764 Finland 1766 Phone: +358 (50) 4871445 1767 Email: Hannes.Tschofenig@gmx.net 1768 URI: http://www.tschofenig.priv.at 1770 Mayutan Arumaithurai 1771 University of Goettingen 1773 Email: mayutan.arumaithurai@gmail.com 1774 Mark Jones (editor) 1775 Bridgewater Systems 1776 303 Terry Fox Drive, Suite 500 1777 Ottawa, Ontario K2K 3J1 1778 Canada 1780 Phone: +1 613-591-6655 1781 Email: mark.jones@bridgewatersystems.com 1783 Avi Lior 1784 Bridgewater Systems 1785 303 Terry Fox Drive, Suite 500 1786 Ottawa, Ontario K2K 3J1 1787 Canada 1789 Phone: +1 613-591-6655 1790 Email: avi@bridgewatersystems.com