RFC 5777
Traffic Classification and Quality of Service (QoS) Attributes for Diameter
🎀 RFC 5777: Traffic Classification and QoS Attributes for Diameter 🎀
okay bestie, this RFC is literally the Diameter world's filter-and-QoS glow-up 💅 It's RFC 5777, a Standards Track document from February 2010, with ISSN 2070-1721. The authors are J. Korhonen and H. Tschofenig (Nokia Siemens Networks), M. Arumaithurai (University of Goettingen), M. Jones, Ed. and A. Lior (Bridgewater Systems). The header doesn't list any "Obsoletes" or "Updates" entry, so it isn't marked as replacing or patching another RFC there, though the Introduction does talk about the work of updating RFC 3588 🌸
Abstract
okay so the whole point is it defines a bunch of Diameter AVPs (attribute-value pairs) 🦋 for traffic classification, with actions for filtering and Quality of Service (QoS) treatment. You can use these in existing and future Diameter applications, as long as the ABNF (Augmented Backus-Naur Form) spec of the Diameter command extension you're working with allows it ✨
Status of This Memo
this is an Internet Standards Track document 🫶
it's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more info on Internet Standards, check Section 2 of RFC 5741 📚
for the current status, any errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc5777 💜
Copyright Notice
Copyright (c) 2010 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, which you can read at http://trustee.ietf.org/license-info as they stood on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions 🙈 Any Code Components pulled out of this document need to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says ✨
this document may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. Some of that material's copyright holders may not have let the IETF Trust allow modifications outside the IETF Standards Process. So unless you get a proper license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🫧
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Rule Sets and Rules .............................................4
3.1. QoS-Resources AVP ..........................................5
3.2. Filter-Rule AVP ............................................5
3.3. Filter-Rule-Precedence AVP .................................6
4. Conditions ......................................................6
4.1. Traffic Classifiers ........................................6
4.1.1. Classifier AVP ......................................8
4.1.2. Classifier-ID AVP ...................................9
4.1.3. Protocol AVP ........................................9
4.1.4. Direction AVP .......................................9
4.1.5. From-Spec AVP .......................................9
4.1.6. To-Spec AVP ........................................10
4.1.7. Source and Destination AVPs ........................11
4.1.8. Header Option AVPs .................................15
4.2. Time Of Day AVPs ..........................................22
4.2.1. Time-Of-Day-Condition AVP ..........................22
4.2.2. Time-Of-Day-Start AVP ..............................23
4.2.3. Time-Of-Day-End AVP ................................23
4.2.4. Day-Of-Week-Mask AVP ...............................23
4.2.5. Day-Of-Month-Mask AVP ..............................24
4.2.6. Month-Of-Year-Mask AVP .............................24
4.2.7. Absolute-Start-Time AVP ............................25
4.2.8. Absolute-Start-Fractional-Seconds AVP ..............25
4.2.9. Absolute-End-Time AVP ..............................25
4.2.10. Absolute-End-Fractional-Seconds AVP ...............25
4.2.11. Timezone-Flag AVP .................................25
4.2.12. Timezone-Offset AVP ...............................26
5. Actions ........................................................26
5.1. Treatment-Action AVP ......................................26
5.2. QoS-Profile-Id AVP ........................................27
5.3. QoS-Profile-Template AVP ..................................27
5.4. QoS-Semantics .............................................28
5.5. QoS-Parameters AVP ........................................29
5.6. Excess-Treatment AVP ......................................29
6. QoS Capability Indication ......................................29
7. Examples .......................................................30
7.1. Diameter EAP with QoS Information .........................30
7.2. Diameter NASREQ with QoS Information ......................32
7.3. QoS Authorization .........................................33
7.4. Diameter Server Initiated Re-Authorization of QoS .........33
7.5. Diameter Credit Control (CC) with QoS Information .........34
7.6. Classifier Examples .......................................35
7.7. QoS Parameter Examples ....................................37
8. Acknowledgments ................................................37
9. Contributors ...................................................37
10. IANA Considerations ...........................................38
10.1. AVP Codes ................................................38
10.2. QoS-Semantics IANA Registry ..............................39
10.3. Action ...................................................40
11. Security Considerations .......................................40
12. References ....................................................40
12.1. Normative References .....................................40
12.2. Informative References ...................................41
Appendix A. MAC and EUI64 Address Mask Usage Considerations ......421. Introduction ✨
okay so this doc is basically the same as the Abstract, just with more context 💖 It defines a bunch of Diameter AVPs for traffic classification, with actions for filtering and QoS treatment. They work in existing and future Diameter apps, provided the ABNF spec of that Diameter command extension allows it 🦋
the story starts way back with the base protocol in RFC 3588 [RFC3588] 🕰️ Filtering and QoS over Diameter were handled by the IPFilterRule AVP and the QoSFilterRule AVP. Both of those used syntax borrowed from the FreeBSD ipfw tool for traffic classification. The QoSFilterRule AVP was underspecified in RFC 3588 [RFC3588], and RFC 4005 [RFC4005] came along later to update it 🧚
then, as part of updating RFC 3588, the IPFilterRule and QoSFilterRule functionality got a full makeover in this document. The goals were a uniform, extensible traffic classification mechanism written in native Diameter syntax, instead of the free text they used before. There's also an extensible set of actions for filtering and QoS treatment, and the QoS side got upgraded to fit today's networking environments 👑
the QoS-Resources AVP is a complete rule set, and each rule is a Filter-Rule AVP. Every rule has three parts: info for handling conflict resolution, a conditions part, and the actions to perform if those conditions are satisfied. The AVPs that express conditions are defined in Section 4 🌷 You can match all or just a subset of the data traffic. That includes matching on Ethernet-specific attributes, which the QoS-Filter-Rule AVP couldn't do 🙈 Service differentiation can be based on Ethernet priority bits, a single layer of VLAN-IDs or stacked VLAN-IDs, Logical Link Control (LLC) attributes, MAC addresses, or any combo of those. The Ethernet header fields are defined in the IEEE802 series of specifications: [IEEE802.2], [IEEE802.1ad], [IEEE802.1Q], and [IEEE802.1D]. And time-based conditions work too, using the attributes in Section 4.2 ⏰
the action part of a rule holds the type of traffic treatment, plus more details about the QoS-related actions 🍓
the QoS policy rules are Diameter encoded AVPs, described using a modified version of ABNF (see [RFC3588]). The AVP datatypes also come from [RFC3588] 💅
2. Terminology
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119]. Those are the official BCP 14 words, so read them carefully 🫶
3. Rule Sets and Rules 💜
like the intro said, the top-level element is the QoS-Resources AVP, and it wraps one or more Filter-Rule AVPs 🎀
3.1. QoS-Resources AVP
the QoS-Resources AVP (AVP Code 508) is Grouped type, and it holds a list of filter policy rules 🌈 Here's its ABNF, kept exactly as it is:
QoS-Resources ::= < AVP Header: 508 >
1*{ Filter-Rule }
* [ AVP ]part 1 of 8 is done, bestie, more coming up next 🧚✨
3.2. Filter-Rule AVP 🎀
okay so the Filter-Rule AVP (AVP Code 509) is a Grouped AVP, and it's basically the whole rule in one box. It bundles a specific condition with a specific action, and it's giving very organized 💅
Filter-Rule ::= < AVP Header: 509 >
[ Filter-Rule-Precedence ]
; Condition part of a Rule
; ------------------------
[ Classifier ]
* [ Time-Of-Day-Condition ]
; Action and Meta-Data
; --------------------
[ Treatment-Action ]
; Info about QoS related Actions
; ------------------------------
[ QoS-Semantics ]
[ QoS-Profile-Template ]
[ QoS-Parameters ]
[ Excess-Treatment ]
; Extension Point
; ---------------
* [ AVP ]ok but here's the tea 🫖 if the QoS-Profile-Template AVP isn't in the Filter-Rule AVP and the Treatment-Action AVP is set to 'shape' or 'mark', then a default gets assumed! The Vendor-Id AVP is 0 (that's IETF) and the QoS-Profile-Id AVP is 0 too (that's the profile from [RFC5624]) ✨. Also, the contents of QoS-Parameters are defined by whatever spec defines those QoS parameters, so go check there 🧚. And when Vendor-Id is 0 and QoS-Profile-Id is 0, the AVPs inside QoS-Parameters are the ones defined in [RFC5624] 🦋
3.3. Filter-Rule-Precedence AVP 👑
The Filter-Rule-Precedence AVP (AVP Code 510) is Unsigned32 and it decides the order the rules run in, the ones listed in the QoS-Resources AVP 🌸. Lower number means higher precedence, so the lowest number is the VIP 💜. Rules with the same precedence MAY be run in parallel, but only if the Resource Management Function supports it 🔥. And if the Filter-Rule-Precedence AVP is missing from the Filter-Rule AVP, the rules SHOULD run in the order they show up in the QoS-Resources AVP. That's the default energy, bestie 🫶
4. Conditions ✨
This section is all about the condition part of a rule 💖 There are two condition types in this document: packet classification conditions, which show up as the Classifier AVP, and time of day conditions, which show up as the Time-Of-Day-Condition AVP 🎀
If there's more than one Time-Of-Day-Condition AVP in the Filter-Rule AVP, the current time at rule evaluation MUST be inside at least one of the time windows from those Time-Of-Day-Condition AVPs. Main character timing ⏰
When the Time-Of-Day-Condition AVP and the Classifier AVP are both in the same Filter-Rule AVP, then BOTH the time of day and the packet classification conditions MUST match before the traffic treatment action gets applied. Both have to be true, no exceptions 💅
4.1. Traffic Classifiers 🦋
Classifiers are used all over the place to pick out a subset of data packets so the action part of a rule can treat them. For example, in a QoS setup, if a packet matches a classifier, it gets treated according to the QoS spec tied to that classifier 🌈 Here's a typical deployment:
+-----------+
+-----------+|
+--------+ +-------------+ +------------+||
| | IN | | | |||
| +--------->| +------------->| |||
|Managed | | Classifying | | Unmanaged |||
|Terminal| OUT | Entity | | Terminal |||
| |<---------+ |<-------------+ ||+
| | | | | |+
+--------+ +-------------+ +------------+
^
| Classifiers
|
+------+------+
| |
| AAA |
| |
+-------------+Figure 1: Example of a Classifier Architecture 📸
The managed terminal is the one the classifiers are being specified for, and it sits on the left of the Classifying Entity 🧚 The unmanaged terminals are the ones that get packets from the managed terminal or send packets to it, and they're on the right side of the Classifying Entity 💜
The Classifying Entity is in charge of classifying packets coming IN from the managed terminal and packets going OUT to it 🔥
A classifier is a group of attributes that describe how to match a packet 🎀 Each set of attributes talks about parts of the packet, usually the header, so different protocols end up using different attributes 💖 Generally, a classifier has these pieces:
- Identifier: uniquely identifies this classifier and can be used to point at it from some other structure 🆔
- From: the rule for matching the protocol-specific source address(es) of the packet 📍
- To: the rule for matching the protocol-specific destination address(es) of the packet 🎯
- Protocol: says which protocol the packet is matched against 🌸
- Direction: says whether the classifier applies to packets flowing from the managed terminal (IN), to the managed terminal (OUT), or in both directions ↔️
- Options: attributes or properties for each protocol or layer, or values in the header of that protocol or layer. Options let you match on those values 🍓
Every protocol type gets its own set of attributes for building a classifier. Those attributes get grouped into one grouped AVP called a Classifier AVP ✨
4.1.1. Classifier AVP 💅
The Classifier AVP (AVP Code 511) is a grouped AVP made of a bunch of attributes that say how to match a packet 🦋
Classifier ::= < AVP Header: 511 >
{ Classifier-ID }
[ Protocol ]
[ Direction ]
* [ From-Spec ]
* [ To-Spec ]
* [ Diffserv-Code-Point ]
[ Fragmentation-Flag ]
* [ IP-Option ]
* [ TCP-Option ]
[ TCP-Flags ]
* [ ICMP-Type ]
* [ ETH-Option ]
* [ AVP ]4.1.2. Classifier-ID AVP 🆔
The Classifier-ID AVP (AVP Code 512) is OctetString and it uniquely identifies the classifier 🎀 Each application decides how unique the ID has to be, like unique per terminal or globally unique 🌍 Exactly one Classifier-ID AVP MUST be inside a Classifier AVP. No more, no less, bestie 💖
4.1.3. Protocol AVP 🌐
The Protocol AVP (AVP Code 513) is Enumerated and says which protocol is being matched 🧚 The attributes in the Classifier AVP MUST be consistent with the value of the Protocol AVP, so don't mix things up 🙈 There can be exactly zero or one Protocol AVP in a Classifier AVP. If you leave the Protocol AVP out, then the protocol of the packet doesn't get compared at all 🫶 The values for this AVP are managed by IANA under the Protocol Numbers registry, which is defined in [RFC2780] 📚
4.1.4. Direction AVP ↔️
The Direction AVP (AVP Code 514) is Enumerated and says which direction the classifier should apply to. The enum values are "IN", "OUT", and "BOTH" 🌈 For "IN" and "BOTH", the From-Spec is the address of the managed terminal and the To-Spec is the unmanaged terminal. For "OUT", it flips: the From-Spec is the unmanaged terminal and the To-Spec is the managed terminal 🔄 If you leave the Direction AVP out, the classifier matches packets flowing in both directions 💜
Value | Name and Semantic
------+--------------------------------------------------
0 | IN - The classifier applies to flows from the
| managed terminal.
1 | OUT - The classifier applies to flows to the
| managed terminal.
2 | BOTH - The classifier applies to flows both to
| and from the managed terminal.4.1.5. From-Spec AVP 📍
The From-Spec AVP (AVP Code 515) is a grouped AVP that specifies the Source Specification used to match the packet 🎯 There can be zero or more of these in a classifier. If it's absent, then every packet matches no matter what the source address is 🌟 If there's more than one From-Spec AVP in the classifier, then the packet's source can match ANY of them 💅 The stuff inside this AVP depends on the protocol 🦋
If one instance (or several) of the IP address AVPs (IP-Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) shows up in the From-Spec AVP, then the source IP address of the packet MUST match one of the addresses those AVPs represent 🌐
If more than one of the layer 2 address AVPs (MAC-Address, MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) shows up in the From-Spec, then the source layer 2 address of the packet MUST match one of the addresses in those AVPs 🔌
If more than one of the port AVPs (Port, Port-Range) shows up in the From-Spec AVP, then the source port number MUST match one of the port numbers in those AVPs 🚪
If the IP address, MAC address, and port AVPs all appear in the same From-Spec AVP, then the source packet MUST match ALL of the specifications, so IP address AND MAC address AND port number. Triple check, periodt 🔥
From-Spec ::= < AVP Header: 515 >
* [ 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 ]4.1.6. To-Spec AVP 🎯
okay so the To-Spec AVP (AVP Code 516) is a grouped AVP that says which Destination Specification to match the packet against 💖. You can have zero or more of these in the classifier. If it's missing, every packet matches no matter where it's going 🦋. If there's more than one, the packet's destination can match any one of the To-Spec AVPs 💅. Its contents depend on the protocol.
if one IP address AVP (IP-Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) or more shows up in the To-Spec AVP, the packet's destination IP address MUST match one of the addresses those AVPs describe 🌸.
if more than one layer 2 address AVP (MAC-Address, MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) shows up in the To-Spec, the packet's destination layer 2 address MUST match one of the addresses in those AVPs 🫶.
if more than one port AVP (Port, Port-Range) shows up in the To-Spec AVP, the destination port number MUST match one of the port numbers in those AVPs ✨.
if the IP address, MAC address, and port AVPs all live in the same To-Spec AVP, then the destination packet MUST match every single spec. so IP address AND MAC address AND port number 😭🔥.
To-Spec ::= < AVP Header: 516 >
* [ 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 ]4.1.7. Source and Destination AVPs 🧚
for packet classification, the From-Spec and To-Spec can hold the AVPs listed in the subsections below 💜.
4.1.7.1. Negated AVP 🙈
the Negated AVP (AVP Code 517) is an Enumerated type with the values True or False. you can have exactly zero or one of these in a From-Spec or To-Spec AVP 🍓.
when it's True, the match gets flipped. the classifier will match addresses other than the ones the From-Spec or To-Spec describes 🔄. when it's False, or the Negated AVP isn't there at all, the classifier matches the addresses that are described 💖.
negation does NOT touch the port comparisons, bestie. ports keep doing their own thing 💀
Value | Name
------+--------
0 | False
1 | True4.1.7.2. IP-Address AVP 🌈
the IP-Address AVP (AVP Code 518) is an Address type that matches one single IP address (IPv4 or IPv6) 🦋.
4.1.7.3. IP-Address-Range AVP 👑
the IP-Address-Range AVP (AVP Code 519) is a Grouped type that describes an inclusive IP address range 🎀.
IP-Address-Range ::= < AVP Header: 519 >
[ IP-Address-Start ]
[ IP-Address-End ]
* [ AVP ]if IP-Address-Start is left out, the range starts at the very first valid IP address and goes up to and including the IP-Address-End address 🌸.
if IP-Address-End is left out, the range starts at the IP-Address-Start address and includes every remaining valid IP address 🧚.
for an IP-Address-Range AVP to be valid, the IP-Address-Start AVP MUST hold a value that is less than the IP-Address-End AVP 💅.
4.1.7.4. IP-Address-Start AVP 🍓
the IP-Address-Start AVP (AVP Code 520) is an Address type that gives the first IP address (IPv4 or IPv6) of an IP address range ✨.
4.1.7.5. IP-Address-End AVP 💜
the IP-Address-End AVP (AVP Code 521) is an Address type that gives the last IP address (IPv4 or IPv6) of an address range 🫶.
4.1.7.6. IP-Address-Mask AVP 🔥
the IP-Address-Mask AVP (AVP Code 522) is a Grouped type that describes an IP address range using a base IP address plus the bit-width of the mask 🌈. for example, 192.0.2.0/24 matches every IP address from 192.0.2.0 up to and including 192.0.2.255 🦋. the bit-width MUST be valid for the kind of IP address it's paired with 👑.
IP-Address-Mask ::= < AVP Header: 522 >
{ IP-Address }
{ IP-Bit-Mask-Width }
* [ AVP ]4.1.7.7. IP-Mask-Bit-Mask-Width AVP 🎀
the IP-Bit-Mask-Width AVP (AVP Code 523) is an Unsigned32 type. its value is the width of an IP address bit mask 🌸.
4.1.7.8. MAC-Address AVP 🧚
the MAC-Address AVP (AVP Code 524) is an OctetString type that gives one single layer 2 address in MAC-48 format 💖. the value is a 6-octet encoding of the address, just the way it looks in the frame header 🫶.
4.1.7.9. MAC-Address-Mask AVP 💅
the MAC-Address-Mask AVP (AVP Code 525) is a Grouped type that describes a set of MAC addresses with a bit mask. the mask tells you which bits of the MAC addresses have to fit the MAC address you gave 🍓. for example, a MAC-Address-Mask with MAC-Address 00-10-A4-23-00-00 and MAC-Address-Mask-Pattern FF-FF-FF-FF-00-00 matches every MAC address from 00-10-A4-23-00-00 up to and including 00-10-A4-23-FF-FF ✨.
Appendix A covers what you should think about when you're using MAC address masks to build classifiers 📖.
MAC-Address-Mask ::= < AVP Header: 525 >
{ MAC-Address }
{ MAC-Address-Mask-Pattern }
* [ AVP ]4.1.7.10. MAC-Address-Mask-Pattern AVP 🌈
the MAC-Address-Mask-Pattern AVP (AVP Code 526) is an OctetString type. its value is 6 octets that mark which bit positions of a MAC address get used for matching 🦋.
4.1.7.11. EUI64-Address AVP 👑
the EUI64-Address AVP (AVP Code 527) is an OctetString type that gives one single layer 2 address in EUI-64 format 🎀. the value is an 8-octet encoding of the address, as it would appear in the frame header 💜.
4.1.7.12. EUI64-Address-Mask AVP 🌸
the EUI64-Address-Mask AVP (AVP Code 528) is a Grouped type that describes a set of EUI64 addresses with a bit mask. the mask shows which bits of the EUI64 addresses have to fit the EUI64 address you specified 🧚. for example, an EUI64-Address-Mask with EUI64-Address 00-10-A4-FF-FE-23-00-00 and EUI64-Address-Mask-Pattern FF-FF-FF-FF-FF-FF-00-00 matches every EUI64 address from 00-10-A4-FF-FE-23-00-00 up to and including 00-10-A4-FF-FE-23-FF-FF 💖.
Appendix A covers what you should think about when you're using EUI64 address masks to build classifiers 📖.
EUI64-Address-Mask ::= < AVP Header: 528 >
{ EUI64-Address }
{ EUI64-Address-Mask-Pattern }
* [ AVP ]4.1.7.13. EUI64-Address-Mask-Pattern AVP 🫶
the EUI64-Address-Mask-Pattern AVP (AVP Code 529) is an OctetString type. its value is 8 octets that mark which bit positions of an EUI64 address get used for matching 💅.
4.1.7.14. Port AVP 🍓
the Port AVP (AVP Code 530) is an Integer32 type, with a range of 0 to 65535, that specifies port numbers to match ✨. the type of port comes from the Protocol AVP. so if the Protocol AVP is 6 (TCP), then the Port AVP means a TCP port 📖.
4.1.7.15. Port-Range AVP 💜
the Port-Range AVP (AVP Code 531) is a Grouped type that gives an inclusive range of ports 🌈. the port type comes from the Protocol AVP. so if the Protocol AVP is 6 (TCP), the Port-Range AVP is an inclusive range of TCP ports 🦋.
Port-Range ::= < AVP Header: 531 >
[ Port-Start ]
[ Port-End ]
* [ AVP ]if Port-Start is left out, port 0 is assumed. if Port-End is left out, port 65535 is assumed 👑.
4.1.7.16. Port-Start AVP 🎀
the Port-Start AVP (AVP Code 532) is an Integer32 type that gives the first port number of an IP port range 🌸.
4.1.7.17. Port-End AVP 🧚
the Port-End AVP (AVP Code 533) is an Integer32 type that gives the last port number of an IP port range 💖.
4.1.7.18. Use-Assigned-Address AVP 🫶
in some setups, the AAA doesn't know the IP address that's been assigned to the managed terminal by the time the classifier gets sent to the Classifying Entity 😭. the Use-Assigned-Address AVP (AVP Code 534) is an Enumerated type with the values True or False. when it's there and set to True, it stands for the IP address assigned to the managed terminal 💅.
Value | Name
------+--------
0 | False
1 | True4.1.8. Header Option AVPs 🎀
the Classifier AVP can hold one or more of the AVPs below, so you can match on the different IP, TCP, or ICMP header options 🌈.
4.1.8.1. Diffserv-Code-Point AVP 🦋
the Diffserv-Code-Point AVP (AVP Code 535) is an Enumerated type that specifies the Differentiated Services Field Codepoints to match in the IP header 👑. IANA manages the values under the Differentiated Services Field Codepoints registry, as defined in [RFC2474] 🌸.
4.1.8.2. Fragmentation-Flag AVP 🧚
the Fragmentation-Flag AVP (AVP Code 536) is an Enumerated type that specifies the packet fragmentation flags to match in the IP header 💜.
Value | Name and Semantic
------+------------------------------------------------------------
0 | Don't Fragment (DF)
1 | More Fragments (MF)4.1.8.3. IP-Option AVP 💖
the IP-Option AVP (AVP Code 537) is a Grouped type that specifies an IP header option that MUST be matched 🫶.
IP-Option ::= < AVP Header: 537 >
{ IP-Option-Type }
* [ IP-Option-Value ]
[ Negated ]
* [ AVP ]if one or more IP-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 goes together with the IP-Option-Value AVPs to specify IP header options that do NOT match specific values 🙈. the Negated AVP can also be used without the IP-Option-Value AVP, to specify IP headers that do not contain the option type 💅.
4.1.8.4. IP-Option-Type AVP 🍓
the IP-Option-Type AVP (AVP Code 538) is an Enumerated type. its values are managed by IANA under the IP Option Numbers registry, as defined in [RFC2780] ✨.
4.1.8.5. IP-Option-Value AVP 📖
the IP-Option-Value AVP (AVP Code 539) is an OctetString type that holds the option value that must be matched 💜.
4.1.8.6. TCP-Option AVP 🌈
the TCP-Option AVP (AVP Code 540) is a Grouped type that specifies a TCP header option that MUST be matched 🦋.
TCP-Option ::= < AVP Header: 540 >
{ 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 the TCP header option 👑. if the TCP-Option-Value AVP is absent, the option type MUST be present in the TCP header, but the value is wild carded 🎀.
the Negated AVP is used together with the TCP-Option-Value AVPs to specify TCP header options that do NOT match specific values 🌸. the Negated AVP is used without the TCP-Option-Value AVP to specify TCP headers that do not contain the option type 🧚.
4.1.8.7. TCP-Option-Type AVP 💖
the TCP-Option-Type AVP (AVP Code 541) is an Enumerated type. its values are managed by IANA under the TCP Option Numbers registry, as defined in [RFC2780] 🫶.
4.1.8.8. TCP-Option-Value AVP
The TCP-Option-Value AVP 💖 (AVP Code 542) is an OctetString, and it holds the option value that has to get matched 🎀
4.1.8.9. TCP-Flags AVP
The TCP-Flags AVP ✨ (AVP Code 543) is Grouped, and it's the set of TCP control flags you need to match 🧚
TCP-Flags ::= < AVP Header: 543 >
{ TCP-Flag-Type }
[ Negated ]
* [ AVP ]So if the Negated AVP is missing or it's set to False, the TCP-Flag-Type AVP tells you which flags MUST be set 💅 But if Negated is set to True, TCP-Flag-Type tells you which flags MUST be cleared 🙈
4.1.8.10. TCP-Flag-Type AVP
The TCP-Flag-Type AVP 🌸 (AVP Code 544) is an Unsigned32, and it names the TCP control flag types that must be matched. The first 16 bits follow the TCP header format from [RFC3168], and the last 16 bits are unused. Inside those first 16 bits, bits 0 to 3 are unused, and bits 4 to 15 are managed by IANA under the TCP Header Flag registry, as defined in [RFC3168] 📋
4.1.8.11. ICMP-Type
The ICMP-Type AVP 🦋 (AVP Code 545) is Grouped, and it specifies an ICMP message type that must be matched.
ICMP-Type ::= < AVP Header: 545 >
{ ICMP-Type-Number }
* [ ICMP-Code ]
[ Negated ]
* [ AVP ]If the ICMP-Code AVP is present, its value MUST match the one in the ICMP header. If the ICMP-Code AVP is absent, the ICMP type MUST be present in the ICMP header, but the code is wild carded 🃏
The Negated AVP works with the ICMP-Code AVPs to say which ICMP codes do not match specific values 🙅♀️ It can also be used without an ICMP-Code AVP to say which ICMP headers do not contain the ICMP type. So the Negated AVP feature applies to the ICMP-Code AVP when that AVP is present, and when it's absent, the feature applies to the ICMP-Type-Number 🧠
4.1.8.12. ICMP-Type-Number AVP
The ICMP-Type-Number AVP 💜 (AVP Code 546) is Enumerated, and its values are managed by IANA under the ICMP Type Numbers registry, as defined in [RFC2780] 🔢
4.1.8.13. ICMP-Code AVP
The ICMP-Code AVP 🍓 (AVP Code 547) is Enumerated, and its values are managed by IANA under the ICMP Type Numbers registry, as defined in [RFC2780] 🔢
4.1.8.14. ETH-Option AVP
The ETH-Option AVP 🌈 (AVP Code 548) is Grouped, and it covers Ethernet-specific attributes 🫶
ETH-Option ::= < AVP Header: 548 >
{ ETH-Proto-Type }
* [ VLAN-ID-Range ]
* [ User-Priority-Range ]
* [ AVP ]4.1.8.15. ETH-Proto-Type AVP
The Eth-Proto-Type AVP 👑 (AVP Code 549) is Grouped, and it specifies the encapsulated protocol type. ETH-Ether-Type and ETH-SAP are mutually exclusive, so you can't have both 🙅♀️
ETH-Proto-Type ::= < AVP Header: 549 >
* [ ETH-Ether-Type ]
* [ ETH-SAP ]
* [ AVP ]4.1.8.16. ETH-Ether-Type AVP
The ETH-Ether-Type AVP ⭐ (AVP Code 550) is an OctetString. Its value is a double octet holding the Ethertype field value in the packet you want to match. This AVP MAY be present for Digital, Intel, and Xerox (DIX), or when the Subnetwork Access Protocol (SNAP) is present at 802.2. But in that case, the ETH-SAP AVP MUST NOT be present 🚫
4.1.8.17. ETH-SAP AVP
The ETH-SAP AVP 🎀 (AVP Code 551) is an OctetString. Its value is a double octet representing the 802.2 SAP, as specified in [IEEE802.2] 💖 The first octet holds the Destination Service Access Point (DSAP), and the second octet holds the Source Service Access Point (SSAP) 🦋
4.1.8.18. VLAN-ID-Range AVP
The VLAN-ID-Range AVP 🧚 (AVP Code 552) is Grouped, and it specifies the VLAN range to match. VLAN identities are specified either by a single VLAN-ID, according to [IEEE802.1Q], or by a combination of Customer and Service VLAN-IDs, according to [IEEE802.1ad] 🌈
A single VLAN-ID is represented by the C-VID-Start and C-VID-End AVPs, and in that case the S-VID-Start and S-VID-End AVPs SHALL be omitted. If the VLAN-ID-Range AVP is left out of the classifier, then comparing the VLAN identity of the packet doesn't matter at all 🤷♀️
VLAN-ID-Range ::= < AVP Header: 552 >
[ S-VID-Start ]
[ S-VID-End ]
[ C-VID-Start ]
[ C-VID-End ]
* [ AVP ]Here's the list of the possible combinations of the S-VID-Start and S-VID-End AVPs and what each one means 👀
- If the S-VID-Start AVP is present but the S-VID-End AVP is absent, the S-VID-Start AVP value MUST equal the value of the IEEE 802.1ad S-VID bits specified in [IEEE802.1ad] for a successful match.
- If the S-VID-Start AVP is absent but the S-VID-End AVP is present, the S-VID-End AVP value MUST equal the value of the IEEE 802.1ad S-VID bits for a successful match.
- If both the S-VID-Start and S-VID-End AVPs are present and their values are equal, the S-VID-Start AVP value MUST equal the value of the IEEE 802.1ad S-VID bits for a successful match.
- If both the S-VID-Start and S-VID-End AVPs are present and the value of the S-VID-End AVP is greater than the value of the S-VID-Start AVP, the 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 specified, then Ethernet packets without IEEE 802.1ad encapsulation MUST NOT match this classifier.
- If the S-VID-Start and S-VID-End AVPs are omitted, then whether IEEE 802.1ad encapsulation exists, or how the IEEE 802.1ad S-VID bits compare, is irrelevant for this classifier.
And here's the list for the C-VID-Start and C-VID-End AVPs 💅
- If the C-VID-Start AVP is present but the C-VID-End AVP is absent, the C-VID-Start AVP value MUST equal the value of the IEEE 802.1ad C-VID bits specified in [IEEE802.1ad] or the IEEE 802.1Q VLAN-ID bits specified in [IEEE802.1Q] for a successful match.
- If the C-VID-Start AVP is absent but the C-VID-End AVP is present, the C-VID-End AVP value MUST equal the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits for a successful match.
- If both the C-VID-Start and C-VID-End AVPs are present and their values are equal, the C-VID-Start AVP value MUST equal the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits for a successful match.
- If both the C-VID-Start and C-VID-End AVPs are present and the value of the C-VID-End AVP is greater than the value of the C-VID-Start AVP, the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits MUST be greater than or equal to the C-VID-Start AVP value and less than or equal to the C-VID-End AVP value for a successful match. If the C-VID-Start and C-VID-End AVPs are specified, then Ethernet packets without IEEE 802.1ad or IEEE 802.1Q encapsulation MUST NOT match this classifier.
- If the C-VID-Start and C-VID-End AVPs are omitted, then comparing the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits is irrelevant for this classifier.
4.1.8.19. S-VID-Start AVP
The S-VID-Start AVP 🌸 (AVP Code 553) is an Unsigned32. Its value MUST be in the range from 0 to 4095. This AVP gives the start value of the range of S-VID VLAN-IDs to be matched 🫶
4.1.8.20. S-VID-End AVP
The S-VID-End AVP 🍓 (AVP Code 554) is an Unsigned32. Its value MUST be in the range from 0 to 4095. This AVP gives the end value of the range of S-VID VLAN-IDs to be matched 🎯
4.1.8.21. C-VID-Start AVP
The C-VID-Start AVP 🧁 (AVP Code 555) is an Unsigned32. Its value MUST be in the range from 0 to 4095. This AVP gives the start value of the range of C-VID VLAN-IDs to be matched ✨
4.1.8.22. C-VID-End AVP
The C-VID-End AVP 🦄 (AVP Code 556) is an Unsigned32. Its value MUST be in the range from 0 to 4095. This AVP gives the end value of the range of C-VID VLAN-IDs to be matched 💫
4.1.8.23. User-Priority-Range AVP
The User-Priority-Range AVP 👑 (AVP Code 557) is Grouped, and it specifies an inclusive range for matching the user_priority parameter from [IEEE802.1D]. An Ethernet packet containing the user_priority parameter matches this classifier if the value is greater than or equal to Low-User-Priority and less than or equal to High-User-Priority. If this AVP is omitted, then comparing the IEEE 802.1D user_priority parameter for this classifier doesn't matter 🤷♀️
User-Priority-Range ::= < AVP Header: 557 >
* [ Low-User-Priority ]
* [ High-User-Priority ]
* [ AVP ]4.1.8.24. Low-User-Priority AVP
The Low-User-Priority AVP 💜 (AVP Code 558) is an Unsigned32. Its value MUST be in the range from 0 to 7 🔢
4.1.8.25. High-User-Priority AVP
The High-User-Priority AVP 🌈 (AVP Code 559) is an Unsigned32. Its value MUST be in the range from 0 to 7 🔢
4.2. Time Of Day AVPs
In a lot of QoS applications, the QoS specification applied to a traffic flow depends on the time of day when that flow was observed ⏰ The following sections define AVPs that can express one or more time windows, which decide when a traffic treatment action applies to a traffic flow 🪩
4.2.1. Time-Of-Day-Condition AVP
The Time-Of-Day-Condition AVP 🕰️ (AVP Code 560) is Grouped, and it specifies one or more time windows.
Time-Of-Day-Condition ::= < AVP Header: 560 >
[ 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 ]For example, a time window for 9 a.m. to 5 p.m. (local time), from Monday to Friday, would look like this 📅
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
The Time-Of-Day-Start AVP ☀️ (AVP Code 561) is an Unsigned32. Its value MUST be in the range from 0 to 86400. This AVP gives the start of an inclusive time window, written as the offset 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
The Time-Of-Day-End AVP 🌇 (AVP Code 562) is an Unsigned32. Its value MUST be in the range from 1 to 86400. This AVP gives the end of an inclusive time window, written as the offset 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 🗓️
Okay so the Day-Of-Week-Mask AVP (AVP Code 563) is type Unsigned32, and it's a bit mask that says which day of the week the time window should match 💅 This doc defines these bits:
Bit | Name
------+------------
0 | SUNDAY
1 | MONDAY
2 | TUESDAY
3 | WEDNESDAY
4 | THURSDAY
5 | FRIDAY
6 | SATURDAYThe bit MUST be set for the time window to match on the corresponding day of the week. Bit 0 is the least significant bit, and unused bits MUST be cleared. If this AVP is absent from the Time-Of-Day-Condition AVP, then the time windows match on all days of the week 🌈
4.2.5. Day-Of-Month-Mask AVP 🌙
The Day-Of-Month AVP (AVP Code 564) is type Unsigned32, and yes, the name is a little different from the heading, but that's what the doc says 🙈 The value MUST be in the range from 0 to 2147483647. It's another bit mask, where bit 0 stands for the first day of the month, all the way up to bit 30, which stands for the last day of the month. The bit MUST be set for the time window to match on the corresponding day of the month. Bit 0 is the least significant bit, and unused bits MUST be cleared. If this AVP is absent from the Time-Of-Day-Condition AVP, the time windows match on all days of the month 🍓
4.2.6. Month-Of-Year-Mask AVP 🌸
The Month-Of-Year-Mask AVP (AVP Code 565) is type Unsigned32. It's a bit mask that picks out 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 | DECEMBERThe bit MUST be set for the time window to match on the corresponding month of the year. Bit 0 is the least 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 ⏰
The Absolute-Start-Time AVP (AVP Code 566) is type Time. Its value is the number of seconds since January 1, 1900, 00:00 UTC, and that's when the time window starts 🕰️ If this AVP is absent from the Time-Of-Day-Condition AVP, the time window starts on January 1, 1900, 00:00 UTC.
4.2.8. Absolute-Start-Fractional-Seconds AVP 🫧
The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is type Unsigned32. The value gives the fractional seconds that get added to the Absolute-Start-Time value, so you know exactly when the window starts. If this AVP is absent from the Time-Of-Day-Condition AVP, the fractional seconds are assumed to be zero 💜
4.2.9. Absolute-End-Time AVP 🏁
The Time-Of-Day-End AVP (AVP Code 568) is type Time. Its value is the number of seconds since January 1, 1900, 00:00 UTC, and that's when the time window ends. If this AVP is absent from the Time-Of-Day-Condition AVP, then the time window is open-ended, no cap 🦋
4.2.10. Absolute-End-Fractional-Seconds AVP 🌷
The Absolute-End-Fractional-Seconds AVP (AVP Code 569) is type Unsigned32. The value gives the fractional seconds that get added to the Absolute-End-Time value, which tells you exactly when the window ends. If this AVP is absent from the Time-Of-Day-Condition AVP, then the fractional seconds are assumed to be zero 🎀
4.2.11. Timezone-Flag AVP 🌍
The Timezone-Flag AVP (AVP Code 570) is type Enumerated, and it tells you whether the time windows are written in UTC, in local time at the managed terminal, or as an offset from UTC. If this AVP is absent from the Time-Of-Day-Condition AVP, then the time windows are in UTC. This document defines the following values:
Value | Name and Semantic
------+--------------------------------------------------
0 | UTC - The time windows are expressed in UTC.
1 | LOCAL - The time windows are expressed in local
| time at the managed terminal.
2 | OFFSET - The time windows are expressed as an
| offset from UTC (see Timezone-Offset AVP).4.2.12. Timezone-Offset AVP 🕑
The Timezone-Offset AVP (AVP Code 571) is type Integer32. The value of this AVP MUST be in the range from -43200 to 43200. It gives the offset in seconds from UTC that was used to express the Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month-Mask, and Month-Of-Year-Mask AVPs. This AVP MUST be present if the Timezone-Flag AVP is set to OFFSET 🧚
5. Actions 🎬
This section is all about the actions that go with a rule, and honestly this is where the drama happens 🔥
5.1. Treatment-Action AVP 🎯
The Treatment-Action AVP (AVP Code 572) is type Enumerated, and it lists the actions tied to the condition part of a rule. These are the actions this document defines:
0: drop
1: shape
2: mark
3: permitdrop:
This action means the respective traffic MUST be dropped. Bye bye 👋
shape:
[RFC2475] describes shaping as "the process of delaying packets within a traffic stream to cause it to conform to some defined traffic profile". When the action is set to 'shape', the QoS-Parameters AVP SHALL contain QoS information AVPs, such as the TMOD-1 and Bandwidth AVPs [RFC5624], that indicate how to shape the traffic described by the condition part of the rule 🌊
mark:
[RFC2475] describes marking as "the process of setting the DS codepoint in a packet based on defined rules". When the action is set to 'mark', the QoS-Parameters AVP SHALL contain QoS information AVPs, such as the PHB-Class AVP [RFC5624], that indicate the Diffserv marking to be applied to the traffic described by the condition part of the rule 🏷️
permit:
The 'permit' action is the counterpart to the 'drop' action. It's used to let traffic that matches the condition part of a rule bypass the rule 🫶
[RFC2475] also describes an action called 'policing' as "the process of discarding packets (by a dropper) within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile". This behavior is modeled in the Filter-Rule through the inclusion of the Excess-Treatment AVP containing a Treatment-Action AVP set to 'drop' 💀
Further action values can be registered, as described in Section 10.3 ✨
5.2. QoS-Profile-Id AVP 🪪
The QoS-Profile-Id AVP (AVP Code 573) is type Unsigned32 and holds a QoS profile template identifier. The initial QoS profile template has the value 0 and can be found in [RFC5624]. The registry for the QoS profile templates is created in that same document 📒
5.3. QoS-Profile-Template AVP 🧩
The QoS-Profile-Template AVP (AVP Code 574) is type Grouped. It defines the namespace of the QoS profile, which is indicated in the Vendor-ID AVP, followed by the specific value for the profile.
The Vendor-Id AVP contains a 32-bit IANA Private Enterprise Number (PEN), and the QoS-Profile-Id AVP contains the template identifier assigned by the vendor. The vendor identifier of zero (0) is used for the IETF 🌸
QoS-Profile-Template ::= < AVP Header: 574 >
{ Vendor-Id }
{ QoS-Profile-Id }
* [ AVP ]5.4. QoS-Semantics 🎭
The QoS-Semantics AVP (AVP Code 575) is type Enumerated, and it gives the semantics for the QoS-Profile-Template and QoS-Parameters AVPs in the Filter-Rule AVP. This document defines the following values:
(0): QoS-Desired
(1): QoS-Available
(2): QoS-Delivered
(3): Minimum-QoS
(4): QoS-AuthorizedThe semantics of the QoS parameters depend on the information in the list above. The meaning of each value is laid out in this table 🍒
Object Type Direction Semantic
---------------------------------------------------------------------
QoS-Desired C->S Client requests authorization of the
indicated QoS.
QoS-Desired C<-S NA
QoS-Available C->S Admission Control at client indicates
that this QoS is available. (note 1)
QoS-Available C<-S Admission Control at server indicates
that this QoS is available. (note 2)
QoS-Delivered C->S Client is reporting the actual QoS
delivered to the terminal.
QoS-Delivered C<-S NA
Minimum-QoS C->S Client is not interested in authorizing
QoS that is lower than the indicated QoS.
Minimum-QoS C<-S Client must not provide QoS guarantees
lower than the indicated QoS.
QoS-Authorized C->S NA
QoS-Authorized C<-S Server authorizes the indicated QoS.Legend:
C: Diameter client
S: Diameter server
NA: Not applicable to this document;
no semantic defined in this specificationNotes:
(1) QoS-Available in this direction indicates to the server that
any QoS-Authorized or Minimum-QoS must be less than this
indicated QoS.
(2) QoS-Available in this direction is only useful when the AAA
server performs admission control and knows about the resources
in the network.5.5. QoS-Parameters AVP ⚙️
The QoS-Parameters AVP (AVP Code 576) is type Grouped and holds Quality of Service parameters. These parameters are defined in separate documents and depend on the QoS profile template indicated in the QoS-Profile-Template AVP. For an initial QoS parameter specification, see [RFC5624] 💎
QoS-Parameters ::= < AVP Header: 576 >
* [ AVP ]5.6. Excess-Treatment AVP 🚿
The Excess-Treatment AVP (AVP Code 577) is type Grouped, and it says how out-of-profile traffic is treated. That's traffic not covered by the original QoS-Profile-Template and QoS-Parameters AVPs. The extra Treatment-Action, QoS-Profile-Template, and QoS-Parameters AVPs carried inside the Excess-Treatment AVP describe how the excess traffic gets handled. If the Excess-Treatment AVP is absent, then the treatment of the out-of-profile traffic is left to the discretion of the node performing QoS treatment 🌟
Excess-Treatment ::= < AVP Header: 577 >
{ Treatment-Action }
[ QoS-Profile-Template ]
[ QoS-Parameters ]
* [ AVP ]6. QoS Capability Indication 🛡️
The QoS-Capability AVP (AVP Code 578) is type Grouped and contains a list of supported Quality of Service profile templates, which also tells you what parameter AVPs are supported 🙌
The QoS-Capability AVP can be used for a simple announcement of the QoS capabilities and QoS profiles a peer supports. It can also be used to negotiate a mutually supported set of QoS capabilities and QoS profiles between two peers. In that case, handling failed negotiations is application and/or deployment specific 🤝
QoS-Capability ::= < AVP Header: 578 >
1*{ QoS-Profile-Template }
* [ AVP ]The QoS-Profile-Template AVP is defined in Section 5.3 ✨
7. Examples 🎀
This section shows a few signaling flows where QoS negotiation and authorization are part of the usual NASREQ, EAP, or Credit Control application message exchanges. The signaling flows for the Diameter QoS Application are described in [DIAMETER-QOS] 🦋
7.1. Diameter EAP with QoS Information
okay so, picture a Network Access Server (NAS) that's also a Diameter Client, and it's lowkey showing off its QoS awareness and capabilities 💅. It does this by including them in the DER message as part of the access authentication procedure ✨. Once the EAP exchange wraps up, the Diameter server hands back a pre-provisioned QoS profile in the final Diameter-EAP-Answer (DEA) message, and that profile has the QoS-Semantics in the Filter-Rule AVP set to 'QoS-Authorized' 🎀. Here's the whole flow:
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) |
| | (authorization AVPs) |
| | QoS-Resources(QoS-Authorized) |
| |<-------------------------------|
| | |
| EAP Success | |
|<------------------------------| |
| | |Figure 2: Example of a Diameter EAP Enhanced with QoS Information
7.2. Diameter NASREQ with QoS Information
this one is giving the same pre-provisioned QoS vibes as Figure 2 🦋, except it uses the NASREQ application instead of the 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)|
| |<-----------------------------+
| | |
| Success | |
|<-----------------+ |
| | |Figure 3: Example of a Diameter NASREQ Enhanced with QoS Information
7.3. QoS Authorization
Figure 4 is an authorization-only QoS signaling example that rides along with the NASREQ message exchange 🌈. The NAS hands the Diameter server the "QoS-Desired" QoS-Semantics AVP, and that AVP lives inside the QoS-Resources AVP 🧚. The server then either authorizes the QoS it was asked for or rejects the request and tells the NAS what happened ✨. In this scenario the NAS doesn't need to include the QoS-Capability AVP in the AAR message, because the QoS-Resources AVP implicitly does the same job 💖. Also, the NAS is asking for one specific QoS profile here, not a pre-provisioned one, so it's a different vibe entirely 👑.
End Diameter
Host NAS Server
| | |
| | |
| QoS Request | |
+----------------->| |
| | |
| |AA-Request |
| |Auth-Request-Type=AUTHORIZE_ONLY
| |NASREQ-Payload |
| |QoS-Resources(QoS-Desired) |
| +----------------------------->|
| | |
| | AA-Answer|
| | NASREQ-Payload(Success)|
| | QoS-Resources(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 server-initiated QoS re-authorization procedure 🔥. The Diameter server sends the NAS a Re-Auth Request (RAR) message asking for re-authorization of an existing session, and the NAS replies with a RAA message 💅. The NAS already knows its existing QoS profile and the info for the ongoing session that the Diameter server wants re-authorized 🫶. So the NAS must initiate re-authorization of the existing QoS profile 💜. After that, the re-authorization procedure works exactly like 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) |
| +----------------------------->|
| | |
| | AA-Answer|
| | Result-Code=DIAMETER_SUCCESS|
| | (authorization AVPs)|
| | QoS-Resources(QoS-Authorized)|
| |<-----------------------------+
| | |Figure 5: Example of a Server-Initiated Re-Authorization Procedure
7.5. Diameter Credit Control (CC) with QoS Information
okay so in this one 💅 the CC client sends a QoS authorization request (QoS-Semantics=QoS-Desired) in the very first Credit Control Request (CCR) 🎀. the CC server replies with a Credit Control Answer (CCA) that includes the granted resources with an authorized QoS definition (QoS-Semantics=QoS-Authorized), and then the CC client goes ahead and delivers the service at that QoS ✨
when the service wraps up, the CC client reports the units used, plus the QoS level those units were actually delivered at (QoS-Semantics=QoS-Delivered) 🦋. the end of service can happen for a few reasons: the credit resources granted to the user got used up, the service was successfully delivered, or the service got terminated, e.g., because the Service Element couldn't deliver the service at the authorized QoS level 😭
Service Element
End User (CC Client) CC Server
| | |
|(1) Service Request | |
|-------------------->| |
| |(2) CCR (Initial, |
| | QoS-Resources(QoS-Desired)) |
| |--------------------------------->|
| |(3) CCA (Granted-Units, |
| | QoS-Resources(QoS-Authorized))|
| |<---------------------------------|
|(4) Service Delivery | |
|<------------------->| |
| | |
|(5) End of Service | |
|-------------------->| |
| |(6) CCR (Termination, Used-Units, |
| | QoS-Resources(QoS-Delivered)) |
| |--------------------------------->|
| |(7) CCA |
| |<---------------------------------|
Figure 6: Example of a Diameter Credit Control with QoS Information7.6. Classifier Examples
okay this one is giving classifier vibes 🧚 Example: classify all packets from hosts on subnet 192.0.2.0/24 to ports 80, 8090 or 443 on web servers 192.0.2.123, 192.0.2.124, 192.0.2.125.
Classifier = {
Classifier-Id = "web_svr_example";
Protocol = TCP;
Direction = OUT;
From-Spec = {
IP-Address-Mask = {
IP-Address = 192.0.2.0;
IP-Bit-Mask-Width = 24;
}
}
To-Spec = {
IP-Address = 192.0.2.123;
IP-Address = 192.0.2.124;
IP-Address = 192.0.2.125;
Port = 80;
Port = 8080;
Port = 443;
}
}and now a second one 🌸 Example: any SIP signaling traffic from a device with a MAC address of 01:23:45:67:89:ab to servers with IP addresses in the range 192.0.2.90 to 192.0.2.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 = 192.0.2.90;
IP-Address-End = 192.0.2.190;
}
Port = 5060;
Port = 3478;
Port-Range = {
Port-Start = 16348;
Port-End = 32768;
}
}
}7.7. QoS Parameter Examples
okay so this section is all about how the Diameter QoS AVPs from this document play with the QoS parameters defined in [RFC5624] 🎀 it's a high-level vibe check, not a full walkthrough ✨
first up: say we want a rule that limits traffic to 1 Mbit/s, and any out-of-profile traffic gets dropped. The Classifiers are ignored in this example. For that, the Treatment-Action AVP is set to 'shape', and the QoS-Parameters AVP carries the Bandwidth AVP showing the 1 Mbit/s limit. The Treatment-Action sitting inside the Excess-Treatment AVP is set to 'drop' 💀
now the more complex one 🦋 this time we're doing traffic marking with Diffserv. In-profile traffic (5 Mbit/s in this example) gets associated with PHB-Class "X", and out-of-profile traffic belongs to a different PHB-Class, which in our example is "Y" 🌈
for this, the Treatment-Action AVP is set to 'mark' ✨. the QoS-Parameters AVPs for the conforming traffic hold two AVPs: the TMOD-1 AVP, which describes the traffic characteristics (5 Mbit/s here), and the PHB-Class AVP, set to class "X". then the Excess-Treatment AVP gets included with the Treatment-Action AVP set to 'mark', and its QoS-Parameters AVP carries another PHB-Class AVP that's set to class "Y" 👑
8. Acknowledgments 🫶
we'd like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Tolga Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina Tsou, Pete McCann, Georgios Karagiannis, Elwyn Davies, Max Riegel, Yong Li, and Eric Gray for their comments 💖. we also thank Victor Fajardo for his job as PROTO document shepherd 🍓. and finally, we'd like to thank Lars Eggert, Magnus Westerlund, Adrian Farrel, Lisa Dusseault, Ralph Droms, and Eric Gray for their feedback during the IESG review phase 🔥
9. Contributors 🧚
Max Riegel contributed the VLAN sections ✨
10. IANA Considerations 🎀
10.1. AVP Codes
okay so IANA allocated codes from the "AVP Codes" registry under Authentication, Authorization, and Accounting (AAA) Parameters for the AVPs defined in this document 📋 here's the full list 💅
+-------------------------------------------------------------------+
| AVP Section |
| Attribute Name Code Defined Data Type |
+-------------------------------------------------------------------+
|QoS-Resources 508 3.1 Grouped |
|Filter-Rule 509 3.2 Grouped |
|Filter-Rule-Precedence 510 3.3 Unsigned32 |
|Classifier 511 4.1.1 Grouped |
|Classifier-ID 512 4.1.2 OctetString |
|Protocol 513 4.1.3 Enumerated |
|Direction 514 4.1.4 Enumerated |
|From-Spec 515 4.1.5 Grouped |
|To-Spec 516 4.1.6 Grouped |
|Negated 517 4.1.7.1 Enumerated |
|IP-Address 518 4.1.7.2 Address |
|IP-Address-Range 519 4.1.7.3 Grouped |
|IP-Address-Start 520 4.1.7.4 Address |
|IP-Address-End 521 4.1.7.5 Address |
|IP-Address-Mask 522 4.1.7.6 Grouped |
|IP-Mask-Bit-Mask-Width 523 4.1.7.7 Unsigned32 |
|MAC-Address 524 4.1.7.8 OctetString |
|MAC-Address-Mask 525 4.1.7.9 Grouped |
|MAC-Address-Mask-Pattern 526 4.1.7.10 OctetString |
|EUI64-Address 527 4.1.7.11 OctetString |
|EUI64-Address-Mask 528 4.1.7.12 Grouped |
|EUI64-Address-Mask-Pattern 529 4.1.7.13 OctetString |
|Port 530 4.1.7.14 Integer32 |
|Port-Range 531 4.1.7.15 Grouped |
|Port-Start 532 4.1.7.16 Integer32 |
|Port-End 533 4.1.7.17 Integer32 |
|Use-Assigned-Address 534 4.1.7.18 Enumerated |
|Diffserv-Code-Point 535 4.1.8.1 Enumerated |
|Fragmentation-Flag 536 4.1.8.2 Enumerated |
|IP-Option 537 4.1.8.3 Grouped |
|IP-Option-Type 538 4.1.8.4 Enumerated |
|IP-Option-Value 539 4.1.8.5 OctetString |
|TCP-Option 540 4.1.8.6 Grouped |
|TCP-Option-Type 541 4.1.8.7 Enumerated |
|TCP-Option-Value 542 4.1.8.8 OctetString |
|TCP-Flags 543 4.1.8.9 Grouped |
|TCP-Flag-Type 544 4.1.8.10 Unsigned32 |
|ICMP-Type 545 4.1.8.11 Grouped |
|ICMP-Type-Number 546 4.1.8.12 Enumerated |
|ICMP-Code 547 4.1.8.13 Enumerated |
|ETH-Option 548 4.1.8.14 Grouped |
|ETH-Proto-Type 549 4.1.8.15 Grouped |
|ETH-Ether-Type 550 4.1.8.16 OctetString |
|ETH-SAP 551 4.1.8.17 OctetString |
|VLAN-ID-Range 552 4.1.8.18 Grouped |
|S-VID-Start 553 4.1.8.19 Unsigned32 |
|S-VID-End 554 4.1.8.20 Unsigned32 |
|C-VID-Start 555 4.1.8.21 Unsigned32 |
|C-VID-End 556 4.1.8.22 Unsigned32 |
|User-Priority-Range 557 4.1.8.23 Grouped |
|Low-User-Priority 558 4.1.8.24 Unsigned32 |
|High-User-Priority 559 4.1.8.25 Unsigned32 |
|Time-Of-Day-Condition 560 4.2.1 Grouped |
|Time-Of-Day-Start 561 4.2.2 Unsigned32 |
|Time-Of-Day-End 562 4.2.3 Unsigned32 |
|Day-Of-Week-Mask 563 4.2.4 Unsigned32 |
|Day-Of-Month-Mask 564 4.2.5 Unsigned32 |
|Month-Of-Year-Mask 565 4.2.6 Unsigned32 |
|Absolute-Start-Time 566 4.2.7 Time |
|Absolute-Start-Fractional-Seconds 567 4.2.8 Unsigned32 |
|Absolute-End-Time 568 4.2.9 Time |
|Absolute-End-Fractional-Seconds 569 4.2.10 Unsigned32 |
|Timezone-Flag 570 4.2.11 Enumerated |
|Timezone-Offset 571 4.2.12 Integer32 |
|Treatment-Action 572 5.1 Grouped |
|QoS-Profile-Id 573 5.2 Unsigned32 |
|QoS-Profile-Template 574 5.3 Grouped |
|QoS-Semantics 575 5.4 Enumerated |
|QoS-Parameters 576 5.5 Grouped |
|Excess-Treatment 577 5.6 Grouped |
|QoS-Capability 578 6 Grouped |
+-------------------------------------------------------------------+10.2. QoS-Semantics IANA Registry
Okay, bestie, IANA is the official keeper of all the number lists, and for the QoS-Semantics AVP they made a brand-new registry 🗂️ under Authentication, Authorization, and Accounting (AAA) Parameters. These are the values this spec hands out:
(0): QoS-Desired
(1): QoS-Available
(2): QoS-Delivered
(3): Minimum-QoS
(4): QoS-AuthorizedIf anyone wants to add a new value later, that's subject to the Specification Required policy [RFC5226]. Very official, very organized 💅
10.3. Action
Same energy for the Treatment-Action AVP 🎀 It also gets its own brand-new registry under Authentication, Authorization, and Accounting (AAA) Parameters, and this spec allocates these four:
0: drop
1: shape
2: mark
3: permitAgain, adding new values is subject to the Specification Required policy [RFC5226]. Honestly, the IANA girlies have it all sorted 🧚
11. Security Considerations
Okay, this part is seriously important, so listen up 👀 This doc is all about extending Diameter so it can carry Quality of Service info 📦 The security considerations of the Diameter protocol itself have already been discussed in RFC 3588 [RFC3588], so go read that too.
Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol. No skipping this one, bestie 🔥
12. References
12.1. Normative References
Here are the must-read references 📚
- [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.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
- [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
- [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
- [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
12.2. Informative References
These ones are the extra-credit reading 🌸
- [DIAMETER-QOS] Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, Ed., "Diameter Quality of Service Application", Work in Progress, October 2009.
- [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
- [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
- [RFC5624] Korhonen, J., Tschofenig, H., and E. Davies, "Quality of Service Parameters for Usage with Diameter", RFC 5624, August 2009.
Appendix A. MAC and EUI64 Address Mask Usage Considerations ✨
The MAC and EUI64 address bit masks are generally used to classify devices by Organizationally Unique Identifier (OUI) and/or the address blocks belonging to each OUI assignee 🫶 The bit masks are not meant to add any structure to the MAC or EUI64 address space that the IEEE didn't intend. Hands off the IEEE's design, babe!
The MAC address bit mask should be defined as a contiguous series of "N" set bits followed by a contiguous series of "48 - N" clear bits. For example, the MAC address bit mask 0xFF00FF000000 would not be valid 🙈 Similarly, the EUI64 address bit mask should be defined as a contiguous series of "N" set bits followed by a contiguous series of "64 - N" clear bits.
It should also be noted that some OUIs are assigned for use in applications that need number space management at the organization level (for example, LLC/SNAP encoding). Those aren't commonly used for MAC addresses, so keep that in mind 🦋
Authors' Addresses
Meet the squad behind this one 👑
- Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland EMail: jouni.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.com
📦 where this page comes from
- ietf: rfc5777 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms