Diameter Maintenance and J. Korhonen Extensions (DIME)TeliaSonera Internet-DraftH. Tschofenig Internet-Draft Nokia Siemens Networks Intended status: Standards TrackNokia Siemens Networks Expires: May 1, 2009M. Arumaithurai Expires: June 21, 2009 University of Goettingen M. Jones, Ed. A. Lior Bridgewater SystemsOctober 28,December 18, 2008 Quality of Service Attributes for Diameterdraft-ietf-dime-qos-attributes-08.txtdraft-ietf-dime-qos-attributes-09.txt Status of this MemoBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or sheThis Internet-Draft isaware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF inaccordancefull conformance withSection 6the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onMay 1,June 21, 2009. Copyright Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document extends the IPFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.Diameter QoS Defined AVPsRule Sets and Rules . . . . . . . . . . . . . . . . . . . . . 4 3.1.QoS-CapabilityRule-Set AVP . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.QoS-Profile-TemplateRule AVP . . . . . . . . . . . . . . . . .4 3.3. Vendor-Specific-QoS-Profile-Template AVP .. . . . . . . . 43.4. QoS-Resources AVP . . . . . .4. Conditions . . . . . . . . . . . . . .5 3.5. Extended-QoS-Filter-Rule AVP. . . . . . . . . . . . 5 4.1. Traffic Classifiers . . .5 3.6. QoS-Semantics. . . . . . . . . . . . . . . . 5 4.1.1. Classifier AVP . . . . . .5 3.7. QoS-Parameters AVP. . . . . . . . . . . . . . 7 4.1.2. Classifier-ID AVP . . . . . .6 3.8. QoS-Rule-Precedence AVP. . . . . . . . . . . . 8 4.1.3. Protocol AVP . . . . .6 4. Semantics of QoS Parameters. . . . . . . . . . . . . . . . 8 4.1.4. Direction AVP .6 5. Diameter Classifier AVPs. . . . . . . . . . . . . . . . . . .7 5.1. Classifier8 4.1.5. From-Spec AVP . . . . . . . . . . . . . . . . . . . .. .95.2. Classifier-ID4.1.6. To-Spec AVP . . . . . . . . . . . . . . . . . . . .10 5.3. Protocol AVP. 10 4.1.7. Source and Destination AVPs . . . . . . . . . . . . . 11 4.1.8. Header Option AVPs . . . . . . . . .10 5.4. Direction AVP. . . . . . . . . 15 4.2. Time Of Day AVPs . . . . . . . . . . . . .10 5.5. From-Spec AVP. . . . . . . . 21 4.2.1. Time-Of-Day-Condition AVP . . . . . . . . . . . . . .10 5.6. To-Spec21 4.2.2. Time-Of-Day-Start AVP . . . . . . . . . . . . . . . . 22 4.2.3. Time-Of-Day-End AVP . . . . . . .11 5.7. Source and Destination AVPs. . . . . . . . . . 22 4.2.4. Day-Of-Week-Mask AVP . . . . .12 5.7.1. Negated AVP. . . . . . . . . . . . 22 4.2.5. Day-Of-Month-Mask AVP . . . . . . . . .12 5.7.2. IP-Address AVP. . . . . . . 23 4.2.6. Month-Of-Year-Mask AVP . . . . . . . . . . . . .13 5.7.3. IP-Address-Range AVP. . . 23 4.2.7. Absolute-Start-Time AVP . . . . . . . . . . . . . .13 5.7.4. IP-Address-Start AVP. 23 4.2.8. Absolute-End-Time AVP . . . . . . . . . . . . . . . .13 5.7.5. IP-Address-End24 4.2.9. Timezone-Flag AVP . . . . . . . . . . . . . . . . . .13 5.7.6. IP-Address-Mask24 4.2.10. Timezone-Offset AVP . . . . . . . . . . . . . . . . .14 5.7.7. IP-Mask-Bit-Mask-Width AVP24 5. Actions . . . . . . . . . . . . . .14 5.7.8. MAC-Address AVP. . . . . . . . . . . . . 24 5.1. Action AVP . . . . . .14 5.7.9. MAC-Address-Mask AVP. . . . . . . . . . . . . . . . .14 5.7.10. MAC-Address-Mask-Pattern AVP. 24 5.2. Diameter QoS Defined AVPs . . . . . . . . . . . .14 5.7.11. EUI64-Address AVP. . . . 25 5.2.1. QoS-Profile-Id AVP . . . . . . . . . . . . . .15 5.7.12. EUI64-Address-Mask AVP . . . . . . . . . . . . . . . . 15 5.7.13. EUI64-Address-Mask-Pattern AVP . . . . . . . . . . . . 15 5.7.14. Port AVP . . . . . . . . . . . .. . . .. . . . . . . 15 5.7.15. Port-Range25 5.2.2. QoS-Profile-Template AVP . . . . . . . . . . . . . . .. . . . . 15 5.7.16. Port-Start AVP25 5.2.3. QoS-Semantics . . . . . . . . . . . . . . . . . . . .16 5.7.17. Port-End26 5.2.4. QoS-Parameters AVP . . . . . . . . . . . . . . . . . .. . . 16 5.7.18. Use-Assigned-Address27 5.2.5. Rule-Precedence AVP . . . . . . . . . . . . . . .16 5.8. Header Option AVPs . . . . . . . . . . . . . . . .. .. . 16 5.8.1. Diffserv-Code-Point27 5.2.6. Excess-Treatment AVP . . . . . . . . . . . . . . .16 5.8.2. Fragmentation-Flag AVP . . . . . . .. . 28 5.2.7. Excess-Treatment-Action . . . . . . .16 5.8.3. IP-Option AVP. . . . . . . . 28 6. QoS Capability Indication . . . . . . . . . . . .17 5.8.4. IP-Option-Type AVP. . . . . . 29 7. Examples . . . . . . . . . . . .17 5.8.5. IP-Option-Value AVP. . . . . . . . . . . . . . . 29 7.1. Diameter EAP with QoS Information . .17 5.8.6. TCP-Option AVP. . . . . . . . . . 30 7.2. Diameter NASREQ with QoS Information . . . . . . . . . .17 5.8.7. TCP-Option-Type AVP. 31 7.3. QoS Authorization . . . . . . . . . . . . . . . .18 5.8.8. TCP-Option-Value AVP. . . . 32 7.4. Diameter Server Initiated Re-authorization of QoS . . . . 33 7.5. Diameter Credit Control with QoS Information . . . . . . . 34 7.6. Classifier Examples . .18 5.8.9. TCP-Flags AVP. . . . . . . . . . . . . . . . . 35 8. Acknowledgments . . .18 5.8.10. TCP-Flag-Type AVP. . . . . . . . . . . . . . . . . .18 5.8.11. ICMP-Type. . 36 9. Contributors . . . . . . . . . . . . . . . . . . . .19 5.8.12. ICMP-Type-Number AVP. . . . . 36 10. IANA Considerations . . . . . . . . . . . .19 5.8.13. ICMP-Code AVP. . . . . . . . . 36 11. Security Considerations . . . . . . . . . . .19 5.8.14. ETH-Option AVP. . . . . . . . 39 12. References . . . . . . . . . . . .19 5.8.15. ETH-Proto-Type AVP. . . . . . . . . . . . . . 39 12.1. Normative References . . . .20 5.8.16. ETH-Ether-Type AVP. . . . . . . . . . . . . . . 39 12.2. Informative References . . .20 5.8.17. ETH-SAP AVP. . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . .20 5.8.18. VLAN-ID-Range AVP. . . . . . . . . . . . . . . . . .20 5.8.19. S-VID-Start AVP . . . . . . . . . . . . . . . . . . . 21 5.8.20. S-VID-End AVP . . . . . . . . . . . . . . . . . . . . 21 5.8.21. C-VID-Start AVP . . . . . . . . . . . . . . . . . . . 22 5.8.22. C-VID-End AVP . . . . . . . . . . . . . . . . . . . . 22 5.8.23. ETH-Priority-Range AVP . . . . . . . . . . . . . . . . 22 5.8.24. ETH-Low-Priority AVP . . . . . . . . . . . . . . . . . 22 5.8.25. ETH-High-Priority AVP . . . . . . . . . . . . . . . . 22 6. Time Of Day AVPs . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Time-Of-Day-Condition AVP . . . . . . . . . . . . . . . . 23 6.2. Time-Of-Day-Start AVP . . . . . . . . . . . . . . . . . . 23 6.3. Time-Of-Day-End AVP . . . . . . . . . . . . . . . . . . . 24 6.4. Day-Of-Week-Mask AVP . . . . . . . . . . . . . . . . . . . 24 6.5. Day-Of-Month-Mask AVP . . . . . . . . . . . . . . . . . . 24 6.6. Month-Of-Year-Mask AVP . . . . . . . . . . . . . . . . . . 24 6.7. Absolute-Start-Time AVP . . . . . . . . . . . . . . . . . 25 6.8. Absolute-End-Time AVP . . . . . . . . . . . . . . . . . . 25 6.9. Timezone-Flag AVP . . . . . . . . . . . . . . . . . . . . 25 6.10. Timezone-Offset AVP . . . . . . . . . . . . . . . . . . . 26 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Diameter EAP with QoS Information . . . . . . . . . . . . 26 7.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 27 7.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 28 7.4. Diameter Server Initiated Re-authorization of QoS . . . . 29 7.5. Diameter Credit Control with QoS Information . . . . . . . 30 7.6. Classifier Examples . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 12.2. Informative References . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 38 1. Introduction This document defines a number of Diameter Quality of Service (QoS) related AVPs that can be used in existing and future Diameter applications where permitted by the command ABNF. The Extended-QoS- Filter-Rule41 1. Introduction This document defines a number of Diameter Quality of Service (QoS) related AVPs that can be used in existing and future Diameter applications where permitted by the command ABNF. The Rule AVP thereby replaces theIPFilterRule,IPFilterRule AVP, defined in RFC3588bis [I-D.ietf-dime-rfc3588bis],3588 [RFC3588], and theQoS-Filter-Rule,QoS-Filter-Rule AVP, defined in RFC 4005 [RFC4005].2. TerminologyThekey words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"structure of a rule in the entire rule set defined in this documentare to be interpreted as described in RFC 2119 [RFC2119]. 3. Diameter QoS Defined AVPs 3.1. QoS-Capability AVP The QoS-Capability AVP (AVP Code TBD) isconsist oftype Grouped and containsalist of supported Quality of Service profile templates (and therefore the support of the respective parameter AVPs).conditions part and corresponding actions. TheQoS-Capability AVP may be usedAVPs responsible for expressing asimple announcement of the QoS capabilities and QoS profiles supported by a peer. It may also be usedcondition are defined in Section 4. Capabilities tonegotiatematch all or amutually supported setsubset ofQoS capabilities and QoS profiles between two peers. QoS-Capability ::= < AVP Header: XXX > * [ QoS-Profile-Template ] * [ Vendor-Specific-QoS-Profile-Template ] * [ AVP ] 3.2. QoS-Profile-Template AVP The QoS-Profile-Template AVP (AVP Code TBD)the data traffic is provided. Additionally, time-based conditions can be expressed based on the functionality offered in Section 4.2. The action part oftype Unsigned32 anda rule contains information for handling conflict resolution, such as aQoS profile template identifier. An initial QoS profile template is defined withpriority valueof 0 and is described in [I-D.ietf-dime-qos-parameters]. The registryfortheeach individual rule within a rule set, and further description regarding QoSprofile templates is created with the same document. 3.3. Vendor-Specific-QoS-Profile-Template AVPrelated actions. 2. Terminology TheVendor-Specific-QoS-Profile-Template AVP (AVP Code TBD) is of type Groupedkey words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", anddefines a vendor-specific QoS profile template. The Vendor-Id AVP contains a 32 bit IANA SMI Network Management Private Enterprise Code"OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Rule Sets and Rules As mentioned in theQoS-Profile-Template AVP containsintroduction thetemplate identifier assigned bytop-level element is thevendor. Vendor-Specific-QoS-Profile-Template ::= < AVP Header: XXX > { Vendor-Id } { QoS-Profile-Template } * [Rule- Set AVP] 3.4. QoS-Resourcesthat encapsulates one or more Rule AVPs. 3.1. Rule-Set AVP TheQoS-ResourcesRule-Set AVP (AVP Code TBD) is of type Grouped andincludesdescribes adescription of the Qualitylist ofService resources for policing traffic flows. QoS-Resourcespolicies.. Rule-Set ::= < AVP Header: XXX >* [ Extended-QoS-Filter-Rule ]1*{ Rule } * [ AVP ]3.5. Extended-QoS-Filter-Rule3.2. Rule AVPThe Extended-QoS-Filter-RuleTheRule AVP (AVP Code TBD) is of type Grouped and defines a specific condition and action combination. The QoS related actions defined in this document therefore one or more traffic flows together with a set of QoS parameters that should be applied tothe flow(s) by the Resource Management Function. This AVP uses the Classifier AVP (see Section 5) to describe traffic flows. Extended-QoS-Filter-Rule ::= < AVP Header: XXX > { QoS-Semantics } [ QoS-Profile-Template ] [ Vendor-Specific-QoS-Profile-Template ] [ QoS-Parameters ] [ QoS-Rule-Precedence ] [ Classifier ] * [ Time-Of-Day-Condition ] * [ AVP ] Either the QoS-Profile-Template or Vendor-Specific-QoS-Profile- Template AVP MUST appear in the Extended-QoS-Filter-Rule AVP. 3.6. QoS-Semantics The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and provides the semantics for the QoS-Profile-Template and QoS- Parameters AVPs in the Extended-QoS-Filter-Rule AVP. This document defines the following values: (0): QoS-Desired (1): QoS-Available (2): QoS-Reserved (3): Minimum-QoS (4): QoS-Authorized 3.7. QoS-Parameters AVP The QoS-Parameters AVP (AVP Code TBD) is of type OctetString and contains Quality of Service parameters. These parameters are defined in a separate document, see [I-D.ietf-dime-qos-parameters]. 3.8. QoS-Rule-Precedence AVP The QoS-Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and specifies the execution order of the rules expressed in the QoS- Resources AVP. Rules with equal precedence MAY be executed in parallel if supportedthe flow(s) by the Resource Management Function. Rule ::= < AVP Header: XXX > ; Condition part of a Rule ; ------------------------ [ Classifier ] * [ Time-Of-Day-Condition ] ; Action and Meta-Data ; -------------------- [ Action ] [ Rule-Precedence ] ; Info about QoS related Actions ; ------------------------------ [ QoS-Semantics ] [ QoS-Profile-Template ] [ QoS-Parameters ] [ Excess-Treatment ] ; Extension Point ; --------------- * [ AVP ] If theQoS-Rule-PrecedenceQoS-Profile-Template AVP isabsent from the Extended-QoS-Filter-Rule AVP, the rules SHOULD be executed in the order in which they appearnot included in theQoS-Resources AVP. The lower the numerical value of QoS-Rule- Precedence AVP, the higherRule AVP then therule precedence. 4. Semanticsdefault setting is assumed, namely a setting ofQoS Parameters The QoS parameters carried intheQoS-ResourcesVendor-Id AVPmay appear in different messages. The semantic ofto 0 (for IETF) and theQoS parameters depend onQoS-Profile-Id AVP to zero (0) (for theinformation providedprofile defined in [I-D.ietf-dime-qos-parameters]). Note that theQoS-Semantics AVP which currently defines 5 values, namely QoS-Desired (0), QoS-Available (1), QoS-Reserved (2), Minimum-QoS (3), and QoS-Authorized (4). The semanticscontent of thedifferent values are as follows: Object Type Direction Semantic --------------------------------------------------------------------- QoS-Desired C->S Please authorize the indicated QoS QoS-Desired C<-S NA QoS-Available C->S Admission Control at interface indicates that this QoS is available. (note 1) QoS-Available C<-S Indicated QoS is available. (note 2) QoS-Reserved C->S Used for reporting during accounting. QoS-Reserved C<-S NA Minimum-QoS C->S Indicates that the client is not interested in authorizing QoS that is lower than Min. QoS. Minimum-QoS C<-S The client must not provide QoS guarantees lower than Min. QoS. QoS-Authorized C->S NA QoS-Authorized C<-S Indicated QoS authorized Legend: C: Diameter client S: Diameter server NA: Not applicable to this document; no semantic defined in this specification Notes: (1) QoS-Available is only useful in relationship with QoS-Desired (and optionally with Minimum-QoS). (2) QoS-Available is only useful whenQoS-Parameters are defined in theAAA server performs admission controlrespective specification defining the QoS parameters. When the Vendor-Id AVP is set to 0 (for IETF) andknows abouttheresourcesQoS-Profile-Id AVP is set to zero (0) then the AVPs included in thenetwork. 5. Diameter ClassifierQoS-Parameters AVP are the AVPs defined in [I-D.ietf-dime-qos-parameters]. 4. Conditions This section describe the condition part of a rule. 4.1. Traffic Classifiers Classifiers are used in many applications to specify how toclassify packets.select a subset of data packets for subsequent treatment as indicated in the action part of a rule. For example in a QoS application, if a packet matches a classifier then that packet will be treated in accordance with a QoS specification associated with that classifier.The Classifiers are sent to on on-path element (e.g. a router) which uses the classifier to match packets.Figure 1 shows a typical deployment. +-----------+ +-----------+| +--------+ +-------------+ +------------+|| | | IN | | | ||| | +--------->| +------------->| ||| |Managed | | Classifying | | Unmanaged ||| |Terminal| OUT | Entity | | Terminal ||| | |<---------+ |<-------------+ ||+ | | | | | |+ +--------+ +-------------+ +------------+ ^ | Classifiers |+------+-------++------+------+ | | | AAA | | |+--------------++-------------+ Figure 1: Example of a Classifier Architecture The managed terminal, the terminal for which the classifiers are being specified is located on the left of the Classifying Entity. The unmanaged terminal, the terminal that receives packets from the Managed terminal or sends packets to the managed terminal is located to the right side of the Classifying Entity. The Classifying Entity is responsible for classifying packets that are incoming (IN) from the Managed Terminal or packets outgoing (OUT) to the Managed Terminal. A Classifier consists of a group of attributes that specify how to match a packet. Each set of attributes expresses values about aspects of the packet - typically the packet header. Different protocols therefore would use different attributes. In general a Classifier consists of the following: Identifier: The identifier uniquely identifies this classifier and may be used to reference the classifier from another structure. From: Specifies the rule for matching the source part of the packet. To: Specifies the rule for matching the destination part of the packet. Protocol: Specifies the matching protocol of the packet. Direction: Specifies whether the classifier is to apply to packets flowing from the Managed Terminal (IN) or to packets flowing to the Managed Terminal (OUT), or packets flowing in both direction. Options: Associated with each protocol or layer, or various values specific to the header of the protocol or layer. Options allow matching on those values. Each protocol type will have a specific set of attributes that can be used to specify a classifier for that protocol. These attributes will be grouped under a grouped AVP called a Classifier AVP.5.1.4.1.1. Classifier AVP The Classifier AVP (AVP Code TBD) is a grouped AVP that consists of a set of attributes that specify how to match a packet. Classifier ::= < AVP Header: XXX > { Classifier-ID } { Protocol } { Direction } * [ From-Spec ] * [ To-Spec ] * [ Diffserv-Code-Point ] [ Fragmentation-Flag ] * [ IP-Option ] * [ TCP-Option ] [ TCP-Flags ] * [ ICMP-Type ] * [ ETH-Option ] * [ AVP ]5.2.4.1.2. Classifier-ID AVP The Classifier-ID AVP (AVP Code TBD) is of type OctetString and uniquely identifies the classifier. Each application will define the uniqueness scope of this identifier, e.g. unique per terminal or globally unique. Exactly one Classifier-ID AVP MUST be contained within a Classifier AVP.5.3.4.1.3. Protocol AVP The Protocol AVP (AVP Code TBD) is of type Enumerated and specifies the protocol being matched. The attributes included in the Classifier AVP must be consistent with the value of the Protocol AVP. Exactly one Protocol AVP MUST be contained within a Classifier AVP. The values for this AVP are managed by IANA under the Protocol Numbers registry [PROTOCOL].5.4.4.1.4. Direction AVP The Direction AVP (AVP Code TBD) is of type Enumerated that specifies in which direction to apply the Classifier. The values of the enumeration are: "IN","OUT","BOTH". In the "IN" and "BOTH" directions, the From-Spec refers to the address of the Managed Terminal and the To-Spec refers to the unmanaged terminal. In the "OUT" direction, the From-Spec refers to the Unmanaged Terminal whereas the To-Spec refers to the Managed Terminal. Value | Name and Semantic ------+-------------------------------------------------- 0 | RESERVED 1 | IN - The classifier applies to flows from the | Managed Terminal. 2 | OUT - The classifier applies to flows to the | Managed Terminal. 3 | BOTH - The classifier applies to flows both to | and from the Managed Terminal.5.5.4.1.5. From-Spec AVP The From-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the Source Specification used to match the packet. Zero or more of these AVPs may appear in the Classifier. If this AVP is absent from the Classifier then all packets are matched regardless of the source address. If more than one instance of this AVP appears in the Classifier then the source of the packet can match any From-Spec AVP. The contents of this AVP are protocol specific. If more than one instance of the IP address AVPs (IP-Address, IP- Address-Range, IP-Address-Mask, Use-Assigned-Address) appear in the From-Spec AVP then the source IP address of the packet must match one of the addresses represented by these AVPs. If more that one instance of the layer 2 address AVPs (MAC-Address, MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the From-Spec then the the source layer 2 address of the packet must match one of the addresses represented in these AVPs. If more that one instance of the port AVPs (Port, Port-Range) appears in the From-Spec AVP then the source port number must match one of the port numbers represented in these AVPs. If the IP address, MAC address and port AVPs appear in the same From- Spec AVP then the source packet must match all the specifications, i.e. match the IP address AND MAC address AND port number. From-Spec ::= < AVP Header: XXX > * [ IP-Address ] * [ IP-Address-Range ] * [ IP-Address-Mask ] * [ MAC-Address ] * [ MAC-Address-Mask] * [ EUI64-Address ] * [ EUI64-Address-Mask] * [ Port ] * [ Port-Range ] [ Negated ] [ Use-Assigned-Address ] * [ AVP ]5.6.4.1.6. To-Spec AVP The To-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the Destination Specification used to match the packet. Zero or more of these AVPs may appear in the Classifier. If this AVP is absent from the Classifier then all packets are matched regardless of the destination address. If more than one instance of this AVP appears in the Classifier then the destination of the packet can match any To-Spec AVP. The contents of this AVP are protocol specific. If more than one instance of the IP address AVPs (IP-Address, IP- Address-Range, IP-Address-Mask, Use-Assigned-Address) appear in the To-Spec AVP then the destination IP address of the packet must match one of the addresses represented by these AVPs. If more that one instance of the layer 2 address AVPs (MAC-Address, MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the To-Spec then the the destination layer 2 address of the packet must match one of the addresses represented in these AVPs. If more that one instance of the port AVPs (Port, Port-Range) appears in the To-Spec AVP then the destination port number must match one of the port numbers represented in these AVPs. If the IP address, MAC address and port AVPs appear in the same To- Spec AVP then the destination packet must match all the specifications, i.e. match the IP address AND MAC address AND port number. To-Spec ::= < AVP Header: XXX > * [ IP-Address ] * [ IP-Address-Range ] * [ IP-Address-Mask ] * [ MAC-Address ] * [ MAC-Address-Mask] * [ EUI64-Address ] * [ EUI64-Address-Mask] * [ Port ] * [ Port-Range ] [ Negated ] [ Use-Assigned-Address ] * [ AVP ]5.7.4.1.7. Source and Destination AVPs For packet classification the contents of the From-Spec and To-Spec can contain the following AVPs. By combining several of these AVPs within a From-Spec or To-Spec AVP and using more than one From-Spec or To-Spec AVP in the Classifier AVP, one can express many different types of address pools.5.7.1.4.1.7.1. Negated AVP The Negated AVP (AVP Code TBD) of type Enumerated containing the values of True or False. Exactly zero or one of these AVPs may appear in the From-Spec or To-Spec AVP. When set to True the meaning of the match in the To-Spec and From-Spec are negated, causing all other addresses to be matched instead. When set to False, or when the AVP is not included in the From-Spec or To-Spec AVP then the meaning of the match is not inverted, causing only the addresses specified to be matched. Note that the negation does not impact the port comparisons. Value | Name ------+-------- 0 | False 1 | True5.7.2.4.1.7.2. IP-Address AVP The IP-Address AVP (AVP Code TBD) is of type Address and specifies a single IP address (IPv4 or IPv6) address to match.5.7.3.4.1.7.3. IP-Address-Range AVP The IP-Address-Range AVP (AVP Code TBD) is of type Grouped and specifies an inclusive IP address range. IP-Address-Range ::= < AVP Header: XXX > [ IP-Address-Start ] [ IP-Address-End ] * [ AVP ] If the IP-Address-Start AVP is not included then the address range starts from the first valid IP address up to and including the specified IP-Address-End address. If the IP-Address-End AVP is not included then the address range starts at the address specified by the IP-Address-Start AVP and includes all the remaining valid IP addresses. For the IP-Address-Range AVP to be valid, the IP-Address-Start AVP MUST contain a value that is less than that of the IP-Address-End AVP.5.7.4.4.1.7.4. IP-Address-Start AVP The IP-Address-Start AVP (AVP Code TBD) is of type Address and specifies the first IP address (IPv4 or IPv6) address of an IP address range.5.7.5.4.1.7.5. IP-Address-End AVP The IP-Address-End AVP (AVP Code TBD) is of type Address and specifies the last IP address (IPv4 or IPv6) address of an address range.5.7.6.4.1.7.6. IP-Address-Mask AVP The IP-Address-Mask AVP (AVP Code TBD) is of type Grouped and specifies an IP address range using a base IP address and the bit- width of the mask. For example, a range expressed as 1.2.3.0/24 will match all IP addresses from 1.2.3.0 up to and including 1.2.3.255. The bit-width MUST be valid for the type of IP address. IP-Address-Mask ::= < AVP Header: XXX > { IP-Address } { IP-Bit-Mask-Width } * [ AVP ]5.7.7.4.1.7.7. IP-Mask-Bit-Mask-Width AVP The IP-Bit-Mask-Width AVP (AVP Code TBD) is of type OctetString. The value is a single octet and specifies the width of an IP address bit- mask.5.7.8.4.1.7.8. MAC-Address AVP The MAC-Address AVP (AVP Code TBD) is of type OctetString and specifies a single layer 2 address in MAC-48 format. The value is a 6 octets encoding of the address as it would appear in the frame header.5.7.9.4.1.7.9. MAC-Address-Mask AVP The MAC-Address-Mask AVP (AVP Code TBD) is of type Grouped and specifies a set of MAC addresses using a bit mask to indicate the bits of the MAC addresses which must fit to the specified MAC address attribute. For example, a MAC-Address-Mask with the MAC-Address as 00-10-A4-23-00-00 and with a MAC-Address-Mask-Pattern of FF-FF-FF-FF- 00-00 will match all MAC addresses from 00-10-A4-23-00-00 up to and including 00-10-A4-23-FF-FF. MAC-Address-Mask ::= < AVP Header: XXX > { MAC-Address } { MAC-Address-Mask-Pattern } * [ AVP ]5.7.10.4.1.7.10. MAC-Address-Mask-Pattern AVP The MAC-Address-Mask-Pattern AVP (AVP Code TBD) is of type OctetString. The value is a 6 octets specifying the bit positions of a MAC address, that are taken for matching.5.7.11.4.1.7.11. EUI64-Address AVP The EUI64-Address AVP (AVP Code TBD) is of type OctetString and specifies a single layer 2 address in EUI-64 format. The value is a 8 octets encoding of the address as it would appear in the frame header.5.7.12.4.1.7.12. EUI64-Address-Mask AVP The EUI64-Address-Mask AVP (AVP Code TBD) is of type Grouped and specifies a set of EUI64 addresses using a bit mask to indicate the bits of the EUI64 addresses which must fit to the specified EUI64 address attribute. For example, a EUI64-Address-Mask with the EUI64- Address as 00-10-A4-FF-FE-23-00-00 and with a EUI64-Address-Mask- Pattern of FF-FF-FF-FF-FF-FF-00-00 will match all EUI64 addresses from 00-10-A4-FF-FE-23-00-00 up to and including 00-10-A4-FF-FE-23- FF-FF. EUI64-Address-Mask ::= < AVP Header: XXX > { EUI64-Address } { EUI64-Address-Mask-Pattern } * [ AVP ]5.7.13.4.1.7.13. EUI64-Address-Mask-Pattern AVP The EUI64-Address-Mask-Pattern AVP (AVP Code TBD) is of type OctetString. The value is a 8 octets specifying the bit positions of a EUI64 address, that are taken for matching.5.7.14.4.1.7.14. Port AVP The Port AVP (AVP Code TBD) is of type Integer32 in the range of 0 to 65535 and specifies the TCP or UDP port number to match.5.7.15.4.1.7.15. Port-Range AVP The Port-Range AVP (AVP Code TBD) is of type Grouped and specifies an inclusive range of ports. Port-Range ::= < AVP Header: XXX > [ Port-Start ] [ Port-End ] * [ AVP ] If the Port-Start AVP is omitted then port 0 is assumed. If the Port-End AVP is omitted then port 65535 is assumed.5.7.16.4.1.7.16. Port-Start AVP The Port-Start AVP (AVP Code TBD) is of type Integer32 and specifies the first port number of an IP port range.5.7.17.4.1.7.17. Port-End AVP The Port-End AVP (AVP Code TBD) is of type Integer32 and specifies the last port number of an IP port range.5.7.18.4.1.7.18. Use-Assigned-Address AVP In some scenarios, the AAA does not know the IP address assigned to the Managed Terminal at the time that the Classifier is sent to the Classifying Entity. The Use-Assigned-Address AVP (AVP Code TBD) is of type Enumerated containing the values of True or False. When present and set to True, it represents the IP address assigned to the Managed Terminal. Value | Name ------+-------- 0 | False 1 | True5.8.4.1.8. Header Option AVPs The Classifier AVP may contain one or more of the following AVPs to match on the various possible IP, TCP or ICMP header options.5.8.1.4.1.8.1. Diffserv-Code-Point AVP The Diffserv-Code-Point AVP (AVP Code TBD) is of type Enumerated and specifies the Differentiated Services Field Codepoints to match in the IP header. The values are managed by IANA under the Differentiated Services Field Codepoints registry [DSCP].5.8.2.4.1.8.2. Fragmentation-Flag AVP The Fragmentation-Flag AVP (AVP Code TBD) is of type Enumerated and specifies the packet fragmentation flags to match in the IP header. Value | Name and Semantic ------+------------------------------------------------------------ 0 | RESERVED 1 | Don't Fragment (DF) 2 | More Fragments (MF)5.8.3.4.1.8.3. IP-Option AVP The IP-Option AVP (AVP Code TBD) is of type Grouped and specifies an IP header option that must be matched. IP-Option ::= < AVP Header: XXX > { IP-Option-Type } * [ IP-Option-Value ] [ Negated ] * [ AVP ] If one or moreIP-Option-ValueIP-Option-Value AVPs are present, one of the values MUST match the value in the IP header option. If the IP-Option-Value AVP is absent, the option type MUST be present in the IP header but the value is wild carded. The Negated AVP is used in conjunction with the IP-Option-Value AVPs to specify IP header options which do not match specific values. The Negated AVP is used without the IP-Option-Value AVP to specify IP headers which do not contain the option type. 4.1.8.4. IP-Option-Type AVP The IP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the values are managed by IANA under the IP Option Numbers registry [IPOPTIONS]. 4.1.8.5. IP-Option-Value AVP The IP-Option-Value AVP (AVP Code TBD) is of type OctetString and contains the option value that must be matched. 4.1.8.6. TCP-Option AVP The TCP-Option AVP (AVP Code TBD) is of type Grouped and specifies a TCP header option that must be matched. TCP-Option ::= < AVP Header: XXX > { TCP-Option-Type } * [ TCP-Option-Value ] [ Negated ] * [ AVP ] If one or more TCP-Option-Value AVPs are present, one of the values MUST match the value in theIPTCP header option. If theIP-Option-ValueTCP-Option- Value AVP is absent, the option type MUST be present in theIPTCP header but the value is wild carded. The Negated AVP is used in conjunctionwithwhich theIP-Option-ValueTCP-Option-Value AVPs to specifyIPTCP header options which do not match specific values. The Negated AVP is used without theIP-Option-ValueTCP-Option-Value AVP to specifyIPTCP headers which do not contain the option type.5.8.4. IP-Option-Type4.1.8.7. TCP-Option-Type AVP TheIP-Option-TypeTCP-Option-Type AVP (AVP Code TBD) is of type Enumerated and the values are managed by IANA under theIPTCP Option Numbers registry[IPOPTIONS]. 5.8.5. IP-Option-Value[TCPOPTIONS]. 4.1.8.8. TCP-Option-Value AVP TheIP-Option-ValueTCP-Option-Value AVP (AVP Code TBD) is of type OctetString and contains the option value that must be matched.5.8.6. TCP-Option4.1.8.9. TCP-Flags AVP TheTCP-OptionTCP-Flags AVP (AVP Code TBD) is of type Grouped and specifies a set of TCPheader optioncontrol flags that must be matched.TCP-OptionTCP-Flags ::= < AVP Header: XXX > 1* {TCP-Option-TypeTCP-Flag-Type } [ Negated ] * [TCP-Option-ValueAVP ] If the Negated AVP is not present, the TCP-Flag-Type AVPs specifies which flags MUST be set. If the Negated AVP is present, the TCP- Flag-Type AVPs specifies which flags MUST be cleared. 4.1.8.10. TCP-Flag-Type AVP The TCP-Flag-Type AVP (AVP Code TBD) is of type Enumerated and specifies a TCP control flag type that must be matched. Value | Name and Semantic ------+------------------------------------------------------------ 0 | RESERVED 1 | CWR - Congestion Window Reduced. 2 | ECE - ECN-Echo. TCP peer is ECN capable. 3 | URG - URGent pointer field is significant. 4 | ACK - ACKnowledgment field is significant. 5 | PSH - Push function. 6 | RST - Reset the connection. 7 | SYN - Synchronize sequence numbers. 8 | FIN - No more data from sender. 4.1.8.11. ICMP-Type The ICMP-Type AVP (AVP Code TBD) is of type Grouped and specifies a ICMP message type that must be matched. ICMP-Type ::= < AVP Header: XXX > { ICMP-Type-Number } * [ ICMP-Code ] [ Negated ] * [ AVP ] Ifone or more TCP-Option-Value AVPs arethe ICMP-Code AVP is present,one ofthevaluesvalue MUST matchthe valuethat in theTCP header option.ICMP header. If theTCP-Option- ValueICMP-Code AVP is absent, theoptionICMP type MUST be present in theTCPICMP header but thevaluecode is wild carded. The Negated AVP is used in conjunction which theTCP-Option-ValueICMP-Code AVPs to specifyTCP header optionsICMP codes which do not match specific values. The Negated AVP is used without theTCP-Option-ValueICMP-Code AVP to specifyTCPICMP headers which do not contain theoptionICMP type.5.8.7. TCP-Option-Type4.1.8.12. ICMP-Type-Number AVP TheTCP-Option-TypeICMP-Type-Number AVP (AVP Code TBD) is of type Enumerated and the values are managed by IANA under theTCP OptionICMP Type Numbers registry[TCPOPTIONS]. 5.8.8. TCP-Option-Value[ICMPTYPE]. 4.1.8.13. ICMP-Code AVP TheTCP-Option-ValueICMP-Code AVP (AVP Code TBD) is of typeOctetStringEnumerated andcontainstheoption value that must be matched. 5.8.9. TCP-Flagsvalues are managed by IANA under the ICMP Type Numbers registry [ICMPTYPE]. 4.1.8.14. ETH-Option AVP TheTCP-FlagsETH-Option AVP (AVP Code TBD) is of type Grouped and specifiesa set of TCP control flags that must be matched. TCP-FlagsEthernet specific attributes. ETH-Option ::= < AVP Header: XXX >1*{TCP-Flag-TypeETH-Proto-Type } * [NegatedVLAN-ID-Range ] * [ ETH-Priority-Range ] * [ AVP ]If4.1.8.15. ETH-Proto-Type AVP The Eth-Proto-Type AVP (AVP Code TBD) is of type Grouped and specifies theNegatedencapsulated protocol type. ETH-Ether-Type and ETH-SAP are mutually exclusive. ETH-Proto-Type ::= < AVP Header: XXX > * [ ETH-Ether-Type ] * [ ETH-SAP ] * [ AVP ] 4.1.8.16. ETH-Ether-Type AVP The ETH-Ether-Type AVP (AVP Code TBD) isnot present,of type OctetString. The value is a double octet theTCP-Flag-Type AVPs specifies which flags MUST be set. Ifcontains theNegatedvalue of the Ethertype field in the packet to match. This AVP MAY be present in the case of DIX or if SNAP ispresent,present at 802.2 but theTCP- Flag-Type AVPs specifies which flagsETH-SAP AVP MUST NOT becleared. 5.8.10. TCP-Flag-Typepresent in this case. 4.1.8.17. ETH-SAP AVP TheTCP-Flag-TypeETH-SAP AVP (AVP Code TBD) is of typeEnumerated and specifies a TCP control flag type that must be matched. Value | Name and Semantic ------+------------------------------------------------------------ 0 | RESERVED 1 | CWR - Congestion Window Reduced. 2 | ECE - ECN-Echo. TCP peer is ECN capable. 3 | URG - URGent pointer field is significant. 4 | ACK - ACKnowledgment fieldOctetString. The value issignificant. 5 | PSH - Push function. 6 | RST - Reseta double octet representing theconnection. 7 | SYN - Synchronize sequence numbers. 8 | FIN - No more data from sender. 5.8.11. ICMP-Type802.2 SAP as specified in [IEEE802.2]. TheICMP-Typefirst octet contains the DSAP and the second the SSAP. 4.1.8.18. VLAN-ID-Range AVP The VLAN-ID-Range AVP (AVP Code TBD) is of type Grouped and specifies the VLAN range to match. VLAN identities are either specified by aICMP message type that mustsingle VLAN-ID according to [IEEE802.1Q] or by a combination of Customer and Service VLAN-IDs according to [IEEE802.1ad]. The single VLAN-ID is represented by the C-VID-Start and C-VID-End AVPs and the S-VID-Start and S-VID-End AVPs SHALL bematched. ICMP-Typeommitted in this case. If the VLAN-ID-Range AVP is omitted from the Classifier, then comparison of the VLAN identity of the packet is irrelevant. VLAN-ID-Range ::= < AVP Header: XXX >{ ICMP-Type-Number } *[ICMP-CodeS-VID-Start ] [NegatedS-VID-End ] [ C-VID-Start ] [ C-VID-End ] * [ AVP ]IfWhen theICMP-CodeS-VID-Start AVP ispresent,present but the S-VID-End AVP is absent, the S-VID-Start AVP value MUSTmatch thatequal the value of the IEEE 802.1ad S-VID bits specified in [IEEE802.1ad] for a successful match. When both S-VID-Start and S-VID-End AVPs are present, theICMP header.value of the IEEE 802.1ad S-VID bits MUST be greater than or equal to the S-VID- Start AVP value and less than or equal to the S-VID-End AVP value for a successful match. If the S-VID-Start and S-VID-End AVPs are omitted, then existence of IEEE802.1ad encapsulation or comparison of the IEEE 802.1ad S-VID bits is irrelevamt for this Classifier. If theICMP-CodeS-VID-Start and S-VID-End AVPs are specified, then Ethernet packets without IEEE 802.1ad encapsulation MUST NOT match this Classifier. When the C-VID-Start AVP is present but the C-VID-End AVP is absent, theICMP typeC-VID-Start AVP value MUSTbe present inequal theICMP header butvalue of thecode is wild carded. The Negated AVP is usedIEEE 802.1ad C-VID bits specified inconjunction which[IEEE802.1ad] or theICMP-CodeIEEE 802.1Q VLAN-ID bits specified in [IEEE802.1Q] for a successful match. When both C-VID- Start and C-VID-End AVPs are present, the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits MUST be greater than or equal tospecify ICMP codes which do not match specific values. The Negated AVP is used withouttheICMP-CodeC-VID-Start AVP value and less than or equal tospecify ICMP headers which do not containtheICMP type. 5.8.12. ICMP-Type-Number AVP The ICMP-Type-NumberC-VID-End AVP(AVP Code TBD) is of type Enumerated andvalue for a successful match. If thevaluesC-VID-Start and C-VID-End AVPs aremanaged by IANA underomitted, then comparison of theICMP Type Numbers registry [ICMPTYPE]. 5.8.13. ICMP-Code AVP The ICMP-Code AVP (AVP Code TBD)IEEE 802.1ad C-VID bits or IEEE 802.1Q VLAN-ID bits for this Classifier isof type Enumerated andirrelevant. If thevaluesC-VID-Start and C-VID-End AVPs aremanaged by IANA under the ICMP Type Numbers registry [ICMPTYPE]. 5.8.14. ETH-Optionspecified, then Ethernet packets without IEEE 802.1ad or IEEE 802.1Q encapsulation MUST NOT match this Classifier. 4.1.8.19. S-VID-Start AVP TheETH-OptionS-VID-Start AVP (AVP Code TBD) is of typeGrouped and specifies Ethernet specific attributes. ETH-Option ::= < AVP Header: XXX > { ETH-Proto-Type } * [ VLAN-ID-Range ] * [ ETH-Priority-Range ] * [Unsigned32. The value MUST be in the range from 0 to 4095. The value of this AVP] 5.8.15. ETH-Proto-Typespecifies the start value of the range of S-VID VLAN-IDs to be matched. 4.1.8.20. S-VID-End AVP TheEth-Proto-TypeS-VID-End AVP (AVP Code TBD) is of typeGrouped and specifiesUnsigned32. The value MUST be in theencapsulated protocol type. ETH-Ether-Type and ETH-SAP are mutually exclusive. ETH-Proto-Type ::= < AVP Header: XXX > * [ ETH-Ether-Type ] * [ ETH-SAP ] * [range from 0 to 4095. The value of this AVP] 5.8.16. ETH-Ether-Typespecifies the end value of the range of S-VID VLAN-IDs to be matched. 4.1.8.21. C-VID-Start AVP TheETH-Ether-TypeC-VID-Start AVP (AVP Code TBD) is of typeOctetString.Unsigned32. The valueis a double octet the contains the value of the Ethertype fieldMUST be in thepacketrange from 0 tomatch. This4095. The value of this AVPMAY be present inspecifies thecasestart value ofDIX or if SNAP is present at 802.2 buttheETH-SAP AVP MUST NOTrange of C-VID VLAN-IDs to bepresent in this case. 5.8.17. ETH-SAPmatched. 4.1.8.22. C-VID-End AVP TheETH-SAPC-VID-End AVP (AVP Code TBD) is of typeOctetString.Unsigned32. The valueis a double octet representing the 802.2 SAP as specifiedMUST be in[IEEE802.2]. The first octet containstheDSAP andrange from 0 to 4095. The value of this AVP specifies thesecondend value of theSSAP. 5.8.18. VLAN-ID-Rangerange of C-VID VLAN-IDs to be matched. 4.1.8.23. ETH-Priority-Range AVP TheVLAN-ID-RangeETH-Priority-Range AVP (AVP Code TBD) is of type Grouped and specifiesthe VLANan inclusive range tomatch. VLAN identities are eithermatch the user_priority parameter specifiedby a single VLAN-ID according to [IEEE802.1Q] or by a combination of Customer and Service VLAN-IDs according to [IEEE802.1ad]. The single VLAN-ID is represented byin [IEEE802.1D]. An Ethernet packet containing theC-VID-Start and C-VID-End AVPs anduser_priority parameter matches this Classifier if theS-VID-Startvalue is greater than or equal to ETH-Low-Priority andS-VID-End AVPs SHALL be ommitted in this case.less than or equal to ETH-High-Priority. Ifthe VLAN-ID-Rangethis AVP isomitted from the Classifier,omitted, then comparison of theVLAN identity of the packetIEEE 802.1D user_priority parameter for this Classifier is irrelevant.VLAN-ID-RangeETH-Priority-Range ::= < AVP Header: XXX > * [S-VID-Start ] [ S-VID-End ] [ C-VID-StartETH-Low-Priority ] * [C-VID-EndETH-High-Priority ] * [ AVP ]When the S-VID-Start4.1.8.24. ETH-Low-Priority AVPis present but the S-VID-EndThe ETH-Low-Priority AVP (AVP Code TBD) isabsent, the S-VID-Start AVPof type Unsigned32. The value MUSTequalbe in thevaluerange from 0 to 7. 4.1.8.25. ETH-High-Priority AVP The ETH-High-Priority AVP (AVP Code TBD) is ofthe IEEE 802.1ad S-VID bits specifiedtype Unsigned32. The value MUST be in[IEEE802.1ad] for a successful match. When both S-VID-Start and S-VID-Endthe range from 0 to 7. 4.2. Time Of Day AVPsare present,In many QoS applications, thevalueQoS specification applied to the traffic flow is conditional upon the time of day when theIEEE 802.1ad S-VID bits MUSTflow was observed. The following sections define AVPs that can begreater than or equalused tothe S-VID- Start AVP value and less thanexpress one orequalmore time windows which determine when a QoS specification is applicable tothe S-VID-End AVP value forasuccessful match. If the S-VID-Start and S-VID-End AVPs are omitted, then existencetraffic flow. 4.2.1. Time-Of-Day-Condition AVP The Time-Of-Day-Condition AVP (AVP Code TBD) is ofIEEE802.1ad encapsulationtype Grouped and specifies one orcomparison of the IEEE 802.1ad S-VID bits is irrelevamt for this Classifier.more time windows. Time-Of-Day-Condition ::= < AVP Header: XXX > [ Time-Of-Day-Start ] [ Time-Of-Day-End ] [ Day-Of-Week-Mask ] [ Day-Of-Month-Mask ] [ Month-Of-Year-Mask ] [ Absolute-Start-Time ] [ Absolute-End-Time ] [ Timezone-Flag ] * [ AVP ] Ifthe S-VID-Start and S-VID-End AVPs are specified, then Ethernet packets without IEEE 802.1ad encapsulation MUST NOT matchmore than one instance of thisClassifier. When the C-VID-StartAVP is presentbutin theC-VID-End AVP is absent,Rule AVP, theC-VID-Start AVP valuecurrent time at QoS rule evaluation MUSTequal the valuebe within at least one of theIEEE 802.1ad C-VID bits specified in [IEEE802.1ad] or the IEEE 802.1Q VLAN-ID bitstime windows specified in[IEEE802.1Q] for a successful match. When both C-VID- Start and C-VID-End AVPs are present, the valueone of theIEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits MUST be greater than or equal toTime-Of-Day-Condition AVPs. When theC-VID-StartTime-Of-Day-Condition AVPvalueandless than or equal to the C-VID-EndClassifier AVPvalue for a successful match. If the C-VID-Start and C-VID-End AVPsareomitted, then comparison ofpresent in theIEEE 802.1ad C-VID bits or IEEE 802.1Q VLAN-ID bits for this Classifier is irrelevant. Ifsame Rule AVP, both theC-VID-Starttime of day andC-VID-End AVPs are specified, then Ethernet packets without IEEE 802.1ad or IEEE 802.1Q encapsulationpacket classification conditions MUSTNOTmatchthis Classifier. 5.8.19. S-VID-Startfor the QoS specification to be applied. For example, a time window for 9am to 5pm (local time) from Monday to Friday would be expressed as: Time-Of-Day-Condition = { Time-Of-Day-Start = 32400; Time-Of-Day-End = 61200; Day-Of-Week-Mask = ( MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY ); Timezone-Flag = LOCAL; } 4.2.2. Time-Of-Day-Start AVP TheS-VID-StartTime-Of-Day-Start AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from 0 to4095.86400. The value of this AVP specifies the startvalueof an inclusive time window expressed as therange of S-VID VLAN-IDs to be matched. 5.8.20. S-VID-Endoffset in seconds from midnight. If this AVP is absent from the Time-Of-Day-Condition AVP, the time window starts at midnight. 4.2.3. Time-Of-Day-End AVP TheS-VID-EndTime-Of-Day-End AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from01 to4095.86400. The value of this AVP specifies the endvalueof an inclusive time window expressed as therange of S-VID VLAN-IDs to be matched. 5.8.21. C-VID-Startoffset in seconds from midnight. If this AVP is absent from the Time-Of- Day-Condition AVP, the time window ends one second before midnight. 4.2.4. Day-Of-Week-Mask AVP TheC-VID-StartDay-Of-Week-Mask AVP (AVP Code TBD) is of type Unsigned32. The value is a bitmask which specifies the day of the week for the time window to match. This document specifies the following bits: Bit | Name ------+------------ 0 | SUNDAY 1 | MONDAY 2 | TUESDAY 3 | WEDNESDAY 4 | THURSDAY 5 | FRIDAY 6 | SATURDAY The bit MUST beinset for therange from 0time window to4095. The valuematch on the corresponding day of the week. Bit 0 is the most significant bit and unused bits MUST be cleared. If this AVPspecifiesis absent from thestart value ofTime-Of-Day- Condition AVP, therangetime windows match on all days ofC-VID VLAN-IDs to be matched. 5.8.22. C-VID-Endthe week. 4.2.5. Day-Of-Month-Mask AVP TheC-VID-EndDay-Of-Week-Month AVP (AVP Code TBD) is of type Unsigned32. The value MUST be in the range from 0 to4095.2147483647. The valueof this AVPis a bitmask which specifies theend valuedays of therangemonth where bit 0 represents the first day ofC-VID VLAN-IDsthe month through tobe matched. 5.8.23. ETH-Priority-Range AVP The ETH-Priority-Range AVP (AVP Code TBD) isbit 30 which represents the last day oftype Grouped and specifies an inclusive rangethe month. The bit MUST be set for the time window to match on theuser_priority parameter specified in [IEEE802.1D]. An Ethernet packet containing the user_priority parameter matches this Classifier ifcorresponding day of thevalue is greater than or equal to ETH-Low-Prioritymonth. Bit 0 is the most significant bit andless than or equal to ETH-High-Priority.unused bits MUST be cleared. If this AVP isomitted, then comparisonabsent from the Time-Of-Day-Condition AVP, the time windows match on all days of theIEEE 802.1D user_priority parameter for this Classifier is irrelevant. ETH-Priority-Range ::= < AVP Header: XXX > * [ ETH-Low-Priority ] * [ ETH-High-Priority ] * [ AVP ] 5.8.24. ETH-Low-Prioritymonth. 4.2.6. Month-Of-Year-Mask AVP TheETH-Low-PriorityMonth-Of-Year-Month AVP (AVP Code TBD) is of type Unsigned32. The value is a bitmask which specifies the months of the year for the time window to match. This document specifies the following bits: Bit | Name ------+----------- 0 | JANUARY 1 | FEBRUARY 2 | MARCH 3 | APRIL 4 | MAY 5 | JUNE 6 | JULY 7 | AUGUST 8 | SEPTEMBER 9 | OCTOBER 10 | NOVEMBER 11 | DECEMBER The bit MUST beinset for therange from 0time window to7. 5.8.25. ETH-High-Prioritymatch on the corresponding month of the year. Bit 0 is the most significant bit and unused bits MUST be cleared. If this AVP is absent from the Time-Of-Day- Condition AVP, the time windows match during all months of the year. 4.2.7. Absolute-Start-Time AVP TheETH-High-PriorityAbsolute-Start-Time AVP (AVP Code TBD) is of typeUnsigned32.Time. The valueMUST be in the range from 0 to 7. 6. Time Of Day AVPs In many QoS applications, the QoS specification applied to the traffic flow is conditional uponof this AVP specifies the timeof dayin seconds since January 1, 1900, 00:00 UTC when theflow was observed. The following sections define AVPs that can be used to express one or moretimewindows which determine when a QoS specificationwindow starts. If this AVP isapplicable to a traffic flow. 6.1.absent from the Time-Of-Day-Condition AVP, the time window starts on January 1, 1900, 00:00 UTC. 4.2.8. Absolute-End-Time AVP TheTime-Of-Day-ConditionTime-Of-Day-End AVP (AVP Code TBD) is of typeGrouped andTime. The value of this AVP specifiesone or morethe timewindows. Time-Of-Day-Condition ::= < AVP Header: XXX > [ Time-Of-Day-Start ] [ Time-Of-Day-End ] [ Day-Of-Week-Mask ] [ Day-Of-Month-Mask ] [ Month-Of-Year-Mask ] [ Absolute-Start-Time ] [ Absolute-End-Time ] [ Timezone-Flag ] * [ AVP ]in seconds since January 1, 1900, 00:00 UTC when the time window ends. Ifmore than one instance ofthis AVP ispresent inabsent from theExtended-QoS- Filter-RuleTime- Of-Day-Condition AVP, thecurrenttimeat QoS rule evaluation MUST be within at least onewindow is open-ended. 4.2.9. Timezone-Flag AVP The Timezone-Flag AVP (AVP Code TBD) is of type Enumerated and indicates whether the time windows are specified inone of the Time- Of-Day-Condition AVPs. WhenUTC, local time at theTime-Of-Day-Condition AVP and Classifiermanaged terminal or as an offset from UTC. If this AVPare present inis absent from thesame Extended-QoS-Filter-RuleTime-Of-Day-Condition AVP,boththe timeof day and packet classification conditions MUST match forwindows are in UTC. This document defines theQoS specification to be applied. For example, afollowing values: Value | Name and Semantic ------+-------------------------------------------------- 0 | RESERVED 1 | UTC - The timewindow for 9am to 5pm (local time) from Monday to Friday would bewindows are expressedas: Time-Of-Day-Condition = { Time-Of-Day-Start = 32400; Time-Of-Day-End = 61200; Day-Of-Week-Mask = ( MONDAYin UTC. 2 |TUESDAYLOCAL - The time windows are expressed in local |WEDNESDAYtime at the Managed Terminal. 3 |THURSDAYOFFSET - The time windows are expressed as an |FRIDAY ); Timezone-Flag = LOCAL; } 6.2. Time-Of-Day-Startoffset from UTC (see Timezone-Offset AVP). 4.2.10. Timezone-Offset AVP TheTime-Of-Day-StartTimezone-Offset AVP (AVP Code TBD) is of typeUnsigned32.Integer32. The value of this AVP MUST be in the range from0-43200 to86400. The value of this AVP43200. It specifies thestart of an inclusive time window expressed as theoffset in seconds frommidnight. If thisUTC that was used to express Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month- Mask and Month-Of-Year-Mask AVPs. This AVPis absent fromMUST be present if theTime-Of-Day-Condition AVP,Timezone-Flag AVP is set to OFFSET. 5. Actions This section illustrates thetime window starts at midnight. 6.3. Time-Of-Day-Endactions associated with a rule. This document only defines QoS specific actions but further actions can be specified as extensions. 5.1. Action AVP TheTime-Of-Day-EndAction AVP (AVP Code TBD) is of typeUnsigned32.Enumerated and lists the actions that are associated with the condition part of a rule. Thevaluefollowing actions are defined in this document: 0: drop 1: shape 2: mark drop: All traffic that is met by the condition part of a rule MUST beindropped. shape: When therange from 1action is set to86400. The value of this'shape', it is expected that the QoS- Parameters AVPspecifiescarries QoS information to indicate how to shape theendtraffic indicated in the condition part ofan inclusive time window expressed astheoffsetrule. mark: When the action is set to 'mark', it is expected that the QoS- Parameters AVP carries information about the QoS class. Further action values can be registered, as described inseconds from midnight. If thisSection 10.4. 5.2. Diameter QoS Defined AVPs 5.2.1. QoS-Profile-Id AVP The QoS-Profile-Id AVP (AVP Code TBD) isabsent fromof type Unsigned32 and contains a QoS profile template identifier. An initial QoS profile template is defined with value of 0 and can be found in [I-D.ietf-dime-qos-parameters]. The registry for theTime-Of- Day-Condition AVP,QoS profile templates is created with thetime window ends one second before midnight. 6.4. Day-Of-Week-Masksame document. 5.2.2. QoS-Profile-Template AVP TheDay-Of-Week-MaskQoS-Profile-Template AVP (AVP Code TBD) is of typeUnsigned32. The value is a bitmask which specifiesGrouped and defines thedaynamespace of theweek forQoS profile (indicated in thetime window to match. This document specifiesVendor-ID AVP) followed by thefollowing bits: Bit | Name ------+------------ 0 | SUNDAY 1 | MONDAY 2 | TUESDAY 3 | WEDNESDAY 4 | THURSDAY 5 | FRIDAY 6 | SATURDAY The bit MUST be setspecific value for thetime window to match on the corresponding day of the week. Bit 0 is the most significantprofile. The Vendor-Id AVP contains a 32 bit IANA SMI Network Management Private Enterprise Code andunused bits MUST be cleared. If thisthe QoS-Profile-Id AVPis absent fromcontains theTime-Of-Day- Condition AVP,template identifier assigned by thetime windows match on all daysvendor. The vendor identifier of zero (0) is used for theweek. 6.5. Day-Of-Month-MaskIETF. QoS-Profile-Template ::= < AVP Header: XXX > { Vendor-Id } { QoS-Profile-Id } * [ AVP ] 5.2.3. QoS-Semantics TheDay-Of-Week-MonthQoS-Semantics AVP (AVP Code TBD) is of typeUnsigned32.Enumerated and provides the semantics for the QoS-Profile-Template and QoS- Parameters AVPs in the Rule AVP. This document defines the following values: (0): QoS-Desired (1): QoS-Available (2): QoS-Reserved (3): Minimum-QoS (4): QoS-Authorized Thevalue MUST besemantic of the QoS parameters depend on the information provided in the list above. The semantics of the different values are as follows: Object Type Direction Semantic --------------------------------------------------------------------- QoS-Desired C->S Please authorize the indicated QoS QoS-Desired C<-S NA QoS-Available C->S Admission Control at interface indicates that this QoS is available. (note 1) QoS-Available C<-S Indicated QoS is available. (note 2) QoS-Reserved C->S Used for reporting during accounting. QoS-Reserved C<-S NA Minimum-QoS C->S Indicates that the client is not interested inthe range from 0 to 2147483647. The valueauthorizing QoS that isa bitmask which specifies the days of the month where bit 0 represents the first day of the month through to bit 30 which represents the last day of the month.lower than Min. QoS. Minimum-QoS C<-S Thebit MUST be set for the time windowclient must not provide QoS guarantees lower than Min. QoS. QoS-Authorized C->S NA QoS-Authorized C<-S Indicated QoS authorized Legend: C: Diameter client S: Diameter server NA: Not applicable tomatch on the corresponding day of the month. Bit 0 is the most significant bit and unused bits MUST be cleared. IfthisAVPdocument; no semantic defined in this specification Notes: (1) QoS-Available isabsent fromonly useful in relationship with QoS-Desired (and optionally with Minimum-QoS). (2) QoS-Available is only useful when theTime-Of-Day-Condition AVP,AAA server performs admission control and knows about thetime windows match on all days ofresources in themonth. 6.6. Month-Of-Year-Masknetwork. 5.2.4. QoS-Parameters AVP TheMonth-Of-Year-MonthQoS-Parameters AVP (AVP Code TBD) is of typeUnsigned32. The value is a bitmask which specifies the monthsgrouped and contains Quality of Service parameters. These parameters are defined in separate documents and depend on theyear for the time window to match. This document specifiesindicated QoS profile template of thefollowing bits: Bit | Name ------+----------- 0 | JANUARY 1 | FEBRUARY 2 | MARCH 3 | APRIL 4 | MAY 5 | JUNE 6 | JULY 7 | AUGUST 8 | SEPTEMBER 9 | OCTOBER 10 | NOVEMBER 11 | DECEMBERQoS-Profile-Template AVP. For an initial QoS parameter specification see [I-D.ietf-dime-qos-parameters]. QoS-Parameters ::= < AVP Header: XXX > * [ AVP ] 5.2.5. Rule-Precedence AVP Thebit MUST be set for the time window to match onRule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and specifies thecorresponding monthexecution order of theyear. Bit 0 isrules expressed in themost significant bit and unused bits MUSTRule-Set AVP. Rules with equal precedence MAY becleared.executed in parallel if supported by the Resource Management Function. Ifthisthe Rule- Precedence AVP is absent from theTime-Of-Day- ConditionRule AVP, thetime windows match during all monthsrules SHOULD be executed in the order in which they appear in the Rule-Set AVP. The lower the numerical value of Rule-Precedence AVP, theyear. 6.7. Absolute-Start-Timehigher the rule precedence. 5.2.6. Excess-Treatment AVP TheAbsolute-Start-TimeExcess-Treatment AVP (AVP Code TBD) is of typeTime. The value of this AVP specifiesgrouped and indicates how out-of- profile traffic, that is, traffic not covered by thetime in seconds since January 1, 1900, 00:00 UTC whenoriginal QoS-Profile-Template and QoS-Parameters AVPs. The additional QoS-Profile-Template and QoS-Parameters AVPs carried inside thetime window starts. If thisExcess-Treatment AVPis absent fromprovide information about theTime-Of-Day-Condition AVP,QoS treatment of thetime window starts on January 1, 1900, 00:00 UTC. 6.8. Absolute-End-Timeexcess traffic. Excess-Treatment ::= < AVP Header: XXX > { Excess-Treatment-Action } [ QoS-Profile-Template ] [ QoS-Parameters ] * [ AVP ] 5.2.7. Excess-Treatment-Action TheTime-Of-Day-EndExcess-Treatment-Action AVP (AVP Code TBD) is of typeTime. The value of thisEnumerated and lists the actions about how the out-of-traffic regarding a specific QoS profile is treated. 0: drop 1: shape 2: remark 3: no metering or policing is permitted drop: When excess treatment action is set to 'drop', all marked traffic MUST be dropped by a QoS aware node. shape: When excess treatment action is set to 'shape', it is expected that the QoS-Parameters AVPspecifiescarries QoS information to what QoS parameter to re-shape thetime in seconds since January 1, 1900, 00:00 UTC whentraffic. An example would be to use the TMOD parameter defined in [I-D.ietf-dime-qos-parameters] and thetime window ends. If this AVPexcess traffic isabsent fromthen to be shaped to this TMOD. When theTime- Of-Day-Condition AVP,shaping causes unbounded queue growth at thetime windowshaper traffic can be dropped. remark: When excess treatment action isopen-ended. 6.9. Timezone-Flag AVP The Timezone-Flag AVP (AVP Code TBD)set to 'remark', it isof type Enumerated and indicates whetherexpected that thetime windows are specified in UTC, local time atQoS-Parameters AVP carries information about themanaged terminal orQoS class. For example, packets may be remarked to drop remarked to pertain to a particular QoS class. In the latter case, remarking relates to a DiffServ-type model, where packets arrive marked asan offset from UTC.belonging to a certain QoS class, and when they are identified as excess, they should then be remarked to a different QoS Class. no metering or policing is permitted: Ifthis AVP'no metering or policing isabsent frompermitted' is signaled, theTime-Of-Day-Condition AVP,QoS aware node should accept thetime windows are in UTC. This document definesexcess treatment parameter set by thefollowing values: Value | Namesender with special care so that excess traffic should not cause a problem. To request the Null Meter [RFC3290] is especially strong, andSemantic ------+-------------------------------------------------- 0 | RESERVED 1 | UTC - The time windows are expressed in UTC. 2 | LOCAL - The time windows are expressed in local | time atshould be used with caution. When theManaged Terminal. 3 | OFFSET - The time windowsExcess-Treatment AVP is omitted then excess treatment is essentially unspecified and there areexpressedno guaranted behavior with regard to excess traffic, i.e., a QoS aware node can do what it finds suitable. Further values can be registered, asan | offset from UTC (see Timezone-Offset AVP). 6.10. Timezone-Offset AVPdescribed in Section 10.3. 6. QoS Capability Indication TheTimezone-OffsetQoS-Capability AVP (AVP Code TBD) is of typeInteger32. The valueGrouped and contains a list ofthissupported Quality of Service profile templates (and therefore the support of the respective parameter AVPs). The QoS-Capability AVPMUSTmay beinused for a simple announcement of therange from -43200 to 43200.QoS capabilities and QoS profiles supported by a peer. Itspecifies the offset in seconds from UTC that wasmay also be used toexpress Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month- Masknegotiate a mutually supported set of QoS capabilities andMonth-Of-Year-Mask AVPs. ThisQoS profiles between two peers. QoS-Capability ::= < AVPMUST be present if the Timezone-FlagHeader: XXX > * [ QoS-Profile-Template ] * [ AVP ] The QoS-Profile-Template AVP isset to OFFSET.defined in Section 5.2.2. 7. Examples This section shows a number of signaling flows where QoS negotiation and authorization is part of the conventional NASREQ, EAP or Credit Control applications message exchanges. The signalling flows for the Diameter QoS Application are described in [I-D.ietf-dime-diameter-qos]. 7.1. Diameter EAP with QoS Information Figure 2 shows a simple signaling flow where a NAS (Diameter Client) announces its QoS awareness and capabilities included into the DER message and as part of the access authentication procedure. Upon completion of the EAP exchange, the Diameter Server provides a pre- provisioned QoS profile with the QoS-Semantics in theExtended-QoS- Filter-RuleRule AVP set to "QoS-Authorized", to the NAS in the final DEA message. End Diameter Diameter Host Client Server | | | | (initiate EAP) | | |<----------------------------->| | | | Diameter-EAP-Request | | | EAP-Payload(EAP Start) | | | QoS-Capability | | |------------------------------->| | | | | | Diameter-EAP-Answer | | Result-Code=DIAMETER_MULTI_ROUND_AUTH | | | EAP-Payload(EAP Request #1) | | |<-------------------------------| | EAP Request(Identity) | | |<------------------------------| | : : : : <<<more message exchanges>>> : : : : | | | | EAP Response #N | | |------------------------------>| | | | Diameter-EAP-Request | | | EAP-Payload(EAP Response #N) | | |------------------------------->| | | | | | Diameter-EAP-Answer | | | Result-Code=DIAMETER_SUCCESS | | | EAP-Payload(EAP Success) | | | [EAP-Master-Session-Key] | | | (authorization AVPs) | | |QoS-Resources(QoS-Authorized)Rule-Set(QoS-Authorized) | | |<-------------------------------| | | | | EAP Success | | |<------------------------------| | | | | Figure 2: Example of a Diameter EAP enhanced with QoS Information 7.2. Diameter NASREQ with QoS Information Figure 3 shows a similar pre-provisioned QoS signaling as in Figure 2 but using the NASREQ application instead of EAP application. End Diameter Host NAS Server | | | | Start Network | | | Attachment | | |<---------------->| | | | | | |AA-Request | | |NASREQ-Payload | | |QoS-Capability | | +----------------------------->| | | | | | AA-Answer| | Result-Code=DIAMETER_MULTI_ROUND_AUTH| | NASREQ-Payload(NASREQ Request #1)| | |<-----------------------------+ | | | | Request | | |<-----------------+ | | | | : : : : <<<more message exchanges>>> : : : : | Response #N | | +----------------->| | | | | | |AA-Request | | |NASREQ-Payload ( Response #N )| | +----------------------------->| | | | | | AA-Answer| | | Result-Code=DIAMETER_SUCCESS| | | (authorization AVPs)| ||QoS-Resources(QoS-Authorized)| Rule-Set(QoS-Authorized) | | |<-----------------------------+ | | | | Success | | |<-----------------+ | | | | Figure 3: Example of a Diameter NASREQ enhanced with QoS Information 7.3. QoS Authorization Figure 4 shows an example of authorization only QoS signaling as part of the NASREQ message exchange. The NAS provides the Diameter server with the "QoS-Desired" QoS-Semantics AVP included in theQoS- ResourcesRule-Set AVP. The Diameter server then either authorizes the indicated QoS or rejects the request and informs the NAS about the result. In this scenario the NAS does not need to include theQoS- CapabilityQoS-Capability AVP in the AAR message as theQoS-ResourcesRule-Set AVP implicitly does the same and also the NAS is authorizing a specific QoS profile, not a pre-provisioned one. End Diameter Host NAS Server | | | | | | | QoS Request | | +----------------->| | | | | | |AA-Request | | |Auth-Request-Type=AUTHORIZE_ONLY | |NASREQ-Payload | ||QoS-Resources(QoS-Desired)|Rule-Set(QoS-Desired) | | +----------------------------->| | | | | | AA-Answer| | | NASREQ-Payload(Success)| | |QoS-Resources(QoS-Authorized)|Rule-Set(QoS-Authorized)| | |<-----------------------------+ | Accept | | |<-----------------+ | | | | | | | | | | Figure 4: Example of an Authorization-Only Message Flow 7.4. Diameter Server Initiated Re-authorization of QoS Figure 5 shows a message exchange for a Diameter server initiated QoS re-authorization procedure. The Diameter server sends the NAS a RAR message requesting re-authorization for an existing session and the NAS acknowledges it with a RAA message. The NAS is aware of its existing QoS profile and information for the ongoing session that the Diameter server requested for re-authorization. Thus, the NAS must initiate re-authorization of the existing QoS profile. The re- authorization procedure is the same as in Figure 4. End Diameter Host NAS Server | | | | | | : : : : <<<Initial Message Exchanges>>> : : : : | | | | | RA-Request | | |<-----------------------------+ | | | | |RA-Answer | | |Result-Code=DIAMETER_SUCCESS | | +----------------------------->| | | | | | | | |AA-Request | | |NASREQ-Payload | | |Auth-Request-Type=AUTHORIZE_ONLY ||QoS-Resources(QoS-Desired)|Rule-Set(QoS-Desired) | | +----------------------------->| | | | | | AA-Answer| | | Result-Code=DIAMETER_SUCCESS| | | (authorization AVPs)| | |QoS-Resources(QoS-Authorized)|Rule-Set(QoS-Authorized) | | |<-----------------------------+ | | | Figure 5: Example of a Server-initiated Re-Authorization Procedure 7.5. Diameter Credit Control with QoS Information In this case the User is charged as soon as the Service Element (CC client) receives the service request. In this case the client uses the "QoS-Desired" QoS-Semantics parameter in theQoS-ResourcesRule-Set AVP that it sends to the Accounitng server. The server responds with a"QoS-Available""QoS- Available" QoS-Semantics parameter in theQoS-ResourcesRule-Set AVP Service Element End User (CC Client) B CC Server | | | | |(1) Service Request | | | |-------------------->| | | | |(2) CCR (event, DIRECT_DEBITING,| | |QoS-Resources[QoS-desired])Rule-Set[QoS-desired]) | | |-------------------------------->| | |(3) CCA (Granted-Units, QoS- | | | Resources[QoS-Authorized]) | | |<--------------------------------| |(4) Service Delivery | | | |<--------------------| | | |(5) Begin service | | | |<------------------------------------>| | | | | | . . . . . . . . Figure 6: Example for a One-Time Diameter Credit Control Charging Event 7.6. Classifier Examples Example: Classify all packets from hosts on subnet 12.34.56.00/24 to ports 80, 8090 or 443 on web servers 23.45.67.123, 23.45.68.124, 23.45.69.125. Classifier = { Classifier-Id = "web_svr_example"; Protocol = TCP; Direction = OUT; From-Spec = { IP-Address-Mask = { IP-Address = 12.34.56.00; IP-Bit-Mask-Width = 24; } } To-Spec = { IP-Address = 23.45.67.123; IP-Address = 23.45.68.124; IP-Address = 23.45.69.125; Port = 80; Port = 8080; Port = 443; } } Example: Any SIP signalling traffic from a device with a MAC address of 01:23:45:67:89:ab to servers with IP addresses in the range 34.56.78.90 to 34.56.78.190. Classifier = { Classifier-Id = "web_svr_example"; Protocol = UDP; Direction = OUT; From-Spec = { MAC-Address = 01:23:45:67:89:ab; } To-Spec = { IP-Address-Range = { IP-Address-Start = 34.56.78.90; IP-Address-End = 34.56.78.190; } Port = 5060; Port = 3478; Port-Range = { Port-Start = 16348; Port-End = 32768; } } } 8. Acknowledgments We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, Jukka Manner, Cornelia Kappler, Xiaoming Fu, FrankAlfano,TolgaAlfano, Tolga Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina Tsou, Pete McCann, Georgios Karagiannis, Elwyn Davies, Max Riegel and Yong Li for their comments. 9. Contributors Max Riegel contributed the VLAN sections. 10. IANA Considerations 10.1. AVP Codes IANA is requested to allocate AVP codes for the following AVPs that are defined in this document.+------------------------------------------------------------------++--------------------------------------------------------------------+ | AVP Section | | Attribute Name Code Defined Data Type |+------------------------------------------------------------------+ |QoS-Capability+--------------------------------------------------------------------+ |Rule-Set TBD 3.1 Grouped ||QoS-Profile-Template|Rule TBD 3.2Unsigned32 | |Vendor-Specific-QoS-Profile-Template TBD 3.3 Grouped | |Extended-QoS-Filter-Rule TBD 3.5Grouped ||QoS-Semantics TBD 3.6 Enumerated | |QoS-Parameters TBD 3.7 OctetString | |QoS-Rule-Precedence TBD 3.8 Unsigned32 ||Classifier TBD5.14.1.1 Grouped | |Classifier-ID TBD5.24.1.2 OctetString | |Protocol TBD5.34.1.3 Enumerated | |Direction TBD5.44.1.4 Enumerated | |From-Spec TBD5.54.1.5 Grouped | |To-Spec TBD5.64.1.6 Grouped | |Negated TBD5.7.14.1.7.1 Enumerated | |IP-Address TBD5.7.24.1.7.2 Address | |IP-Address-Range TBD5.7.34.1.7.3 Grouped | |IP-Address-Start TBD5.7.44.1.7.4 Address | |IP-Address-End TBD5.7.54.1.7.5 Address | |IP-Address-Mask TBD5.7.64.1.7.6 Grouped | |IP-Mask-Bit-Mask-Width TBD5.7.74.1.7.7 OctetString | |MAC-Address TBD5.7.84.1.7.8 OctetString | |MAC-Address-Mask TBD5.7.94.1.7.9 Grouped | |MAC-Address-Mask-Pattern TBD5.7.104.1.7.10 OctetString | |EUI64-Address TBD5.7.114.1.7.11 OctetString | |EUI64-Address-Mask TBD5.7.124.1.7.12 Grouped | |EUI64-Address-Mask-Pattern TBD5.7.134.1.7.13 OctetString | |Port TBD5.7.144.1.7.14 Integer32 | |Port-Range TBD5.7.154.1.7.15 Grouped | |Port-Start TBD5.7.164.1.7.16 Integer32 | |Port-End TBD5.7.174.1.7.17 Integer32 | |Use-Assigned-Address TBD5.7.184.1.7.18 Enumerated | |Diffserv-Code-Point TBD5.8.14.1.8.1 Enumerated | |Fragmentation-Flag TBD5.8.24.1.8.2 Enumerated | |IP-Option TBD5.8.34.1.8.3 Grouped | |IP-Option-Type TBD5.8.44.1.8.4 Enumerated | |IP-Option-Value TBD5.8.54.1.8.5 OctetString | |TCP-Option TBD5.8.64.1.8.6 Grouped | |TCP-Option-Type TBD5.8.74.1.8.7 Enumerated | |TCP-Option-Value TBD5.8.84.1.8.8 OctetString | |TCP-Flags TBD5.8.94.1.8.9 Grouped | |TCP-Flag-Type TBD5.8.104.1.8.10 Enumerated | |ICMP-Type TBD5.8.114.1.8.11 Grouped | |ICMP-Type-Number TBD5.8.124.1.8.12 Enumerated | |ICMP-Code TBD5.8.134.1.8.13 Enumerated | |ETH-Option TBD5.8.144.1.8.14 Grouped | |ETH-Proto-Type TBD5.8.154.1.8.15 Grouped | |ETH-Ether-Type TBD5.8.164.1.8.16 OctetString | |ETH-SAP TBD5.8.174.1.8.17 OctetString | |VLAN-ID-Range TBD5.8.184.1.8.18 Grouped | |S-VID-Start TBD5.8.194.1.8.19 Unsigned32 | |S-VID-End TBD5.8.204.1.8.20 Unsigned32 | |C-VID-Start TBD5.8.214.1.8.21 Unsigned32 | |C-VID-End TBD5.8.224.1.8.22 Unsigned32 | |ETH-Priority-Range TBD5.8.234.1.8.23 Grouped | |ETH-Low-Priority TBD5.8.244.1.8.24 Unsigned32 | |ETH-High-Priority TBD5.8.254.1.8.25 Unsigned32 | |Time-Of-Day-Condition TBD6.14.2.1 Grouped | |Time-Of-Day-Start TBD6.24.2.2 Grouped | |Time-Of-Day-End TBD6.34.2.3 Unsigned32 | |Day-Of-Week-Mask TBD6.44.2.4 Unsigned32 | |Day-Of-Month-Mask TBD6.54.2.5 Unsigned32 | |Month-Of-Year-Mask TBD6.64.2.6 Unsigned32 | |Absolute-Start-Time TBD6.74.2.7 Time | |Absolute-End-Time TBD6.84.2.8 Time | |Timezone-Flag TBD6.94.2.9 Enumerated | |Timezone-Offset TBD6.104.2.10 Integer32 |+------------------------------------------------------------------+|Action TBD 5.1 Grouped | |QoS-Profile-Id TBD 5.2.1 Unsigned32 | |QoS-Profile-Template TBD 5.2.2 Grouped | |QoS-Semantics TBD 5.2.3 Enumerated | |QoS-Parameters TBD 5.2.4 OctetString | |Rule-Precedence TBD 5.2.5 Unsigned32 | |Excess-Treatment TBD 5.2.6 Grouped | |Excess-Treatment-Action TBD 5.2.7 Unsigned32 | |QoS-Capability TBD 6 Grouped | +--------------------------------------------------------------------+ 10.2. QoS-Semantics IANA Registry IANA is also requested to allocate a registry for theQoS-Semantics.QoS-Semantics AVP. The following values are allocated by this specification. (0): QoS-Desired (1): QoS-Available (2): QoS-Reserved (3): Minimum-QoS (4): QoS-Authorized A specification is required to add a new value to the registry. 10.3. Excess Treatment Action IANA is also requested to allocate a registry for the Excess- Treatment-Action AVP. The following values are allocated by this specification: (0): drop (1): shape (2): remark (3): no metering or policing is permitted Astandards track documentspecification is required todepreciate, delete, or modify existing values.add a new value to the registry. 10.4. Action IANA is also requested to allocate a registry for the Action AVP. The following values are allocated by this specification: (0): drop (1): shape (2): mark A specification is required to add a new value to the registry. 11. Security Considerations This document describes the extension of Diameter for conveying Quality of Service information. The security considerations of the Diameter protocol itself have been discussed in RFC3588bis [I-D.ietf-dime-rfc3588bis].3588 [RFC3588]. Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter Base protocol. 12. References 12.1. Normative References [DSCP] IANA,"Differentiated Services Field Codepoints", http://www.iana.org/assignments/dscp-registry. [I-D.ietf-dime-qos-parameters] Korhonen, J. and H. Tschofenig, "Quality of Service Parameters for Usage with the AAA Framework", draft-ietf-dime-qos-parameters-06 (work in progress), May 2008. [I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-12 (work in progress), September 2008."Differentiated Services Field Codepoints", http://www.iana.org/assignments/dscp-registry. [ICMPTYPE] IANA, "ICMP Type Numbers", http://www.iana.org/assignments/icmp-parameters. [IEEE802.1D] IEEE, "IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges", 2004. [IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks, Virtual Bridged Local Area Networks", 2005. [IEEE802.1ad] IEEE, "IEEE Standard for Local and metropolitan area networks, Virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", 2005. [IEEE802.2] IEEE, "IEEE Standard for Information technology, Telecommunications and information exchange between systems, Local and metropolitan area networks, Specific requirements, Part 2: Logical Link Control", 1998. [IPOPTIONS] IANA, "IP Option Numbers", http://www.iana.org/assignments/ip-parameters. [PROTOCOL] IANA, "Protocol Types", http://www.iana.org/assignments/protocol-numbers. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.[TCPOPTIONS] IANA, "TCP Option Numbers", http://www.iana.org/assignments/tcp-parameters. 12.2. Informative References [I-D.ietf-dime-diameter-qos] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality of Service Application", draft-ietf-dime-diameter-qos-06 (work in progress), July 2008. [I-D.ietf-dime-qos-parameters] Korhonen, J. and H. Tschofenig, "Quality of Service Parameters for Usage with the AAA Framework", draft-ietf-dime-qos-parameters-07 (work in progress), November 2008. [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. Authors' Addresses Jouni KorhonenTeliaSonera Teollisuuskatu 13 Sonera FIN-00051Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Email:jouni.korhonen@teliasonera.comjouni.korhonen@nsn.com Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Mayutan Arumaithurai University of Goettingen Email: mayutan.arumaithurai@gmail.com Mark Jones (editor) Bridgewater Systems 303 Terry Fox Drive, Suite 500 Ottawa, Ontario K2K 3J1 Canada Phone: +1 613-591-6655 Email: mark.jones@bridgewatersystems.com Avi Lior Bridgewater Systems 303 Terry Fox Drive, Suite 500 Ottawa, Ontario K2K 3J1 Canada Phone: +1 613-591-6655 Email: avi@bridgewatersystems.comFull Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.