RFC 4323
Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB)
Data Over Cable System Interface Specification: Quality of Service Management Information Base (DOCSIS-QoS MIB) 🎀
Title block tea ☕: this is RFC 4323 from the Network Working Group, written by M. Patrick and W. Murwin (both at Motorola BCS). It's a Standards Track doc, dated January 2006. The header doesn't list anything it obsoletes or updates, so no drama there 💅
Status of This Memo 📜
This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸
Copyright Notice ©️
Copyright (C) The Internet Society (2006).
Abstract ✨
This doc defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs). It covers the Data over Cable System (DOCSIS) specifications versions 1.1 and 2.0 💜
Table of Contents 🧚
1. Introduction ....................................................2
1.1. The Internet-Standard Management Framework .................2
1.2. Glossary ...................................................3
2. Overview ........................................................5
2.1. Textual Conventions ........................................5
2.2. MIB Organization ...........................................5
2.2.1. docsIetfQosPktClassTable ............................9
2.2.2. docsIetfQosParamSetTable ...........................10
2.2.2.1. Interoperation with DOCSIS 1.0 ............11
2.2.3. docsIetfQosServiceFlowTable ........................12
2.2.4. docsIetfQosServiceFlowStatsTable ...................13
2.2.5. docsIetfQosUpstreamStatsTable ......................14
2.2.6. docsIetfQosDynamicServiceStatsTable ................14
2.2.7. docsIetfQosServiceFlowLogTable .....................14
2.2.8. docsIetfQosServiceClassTable .......................15
2.2.9. docsIetfQosServiceClassPolicyTable .................15
2.2.10. docsIetfQosPHSTable ...............................16
2.2.11. docsIetfQosCmtsMacToSrvFlowTable ..................16
3. Externally Administered Classification .........................16
4. DOCSIS and IPv4 Type-of-Service (ToS) Field ....................19
5. Definitions ....................................................20
6. Security Considerations ........................................84
7. IANA Considerations ............................................86
8. Acknowledgements ...............................................86
9. Normative References ...........................................86
10. Informative References ........................................871. Introduction ✨
This memo is a product of the IP over Cable Data Network (IPCDN) working group, which lives inside the Internet Engineering Task Force (IETF) 🦋
1.1. The Internet-Standard Management Framework 🌈
If you want the full tea on the documents that describe the current Internet-Standard Management Framework, look at section 7 of RFC 3410 [15] 👀
Managed objects get accessed through a virtual information store called the Management Information Base, or MIB. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined with the mechanisms in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant with SMIv2, which is described in STD 58, RFC 2578 [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [3] 💅
1.2. Glossary 📖
Here's the vocab list, bestie. Every term is in code so you can spot it easily 🍓
Active QPS: Active QoS Parameter Set (QPS). This is the set of QoS parameters describing the current level of service given to a Service Flow (SF) 🔥Active SF: Active Service Flow. An SF with a non-empty Active QPS.Admitted QPS: Admitted QoS Parameter Set. This is the set of QoS parameters describing a level of service the Service Flow isn't using right now, but that it's guaranteed to get once the SF asks to make the set Active 🫶Admitted SF: A Service Flow with a non-empty Admitted QPS.CATV: Cable Television.CM: Cable Modem. A modem that connects a subscriber's LAN to the Cable Television (CATV) Radio Frequency (RF) network. DOCSIS CMs work as a MAC layer bridge between the home LAN and that CATV RF network 🌸CMTS: Cable Modem Termination System. This is the "head-end" device that connects the RF network to the Internet 🧚Downstream: The direction from the head-end toward the subscriber.DSA: Dynamic Service Addition. A DOCSIS MAC management message that asks for a brand-new Service Flow to be created dynamically. New SFs get made through a three-message exchange of DSA-REQ, DSA-RSP, and DSA-ACK ✨DSC: Dynamic Service Change. A DOCSIS MAC management message that asks for the attributes of a Service Flow to be changed. SFs get changed through a three-message exchange of DSC-REQ, DSC-RSP, and DSC-ACK.DSD: Dynamic Service Delete. A DOCSIS MAC management message that asks for a Service Flow to be deleted. SFs get deleted through a two-message exchange of DSD-REQ and DSD-ACK 💀Head-end: The origination point in most cable systems for the subscriber video signals. It's generally also where the CMTS lives.PHS: Payload Header Suppression. A DOCSIS 1.1 and 2.0 feature where header bytes that are common across a sequence of packets in a Service Flow get swapped for a one-byte PHSI Index (PHSI) when the packet goes out on the RF network 🦋primary SF: Primary Service Flow. All CMs have a Primary Upstream Service Flow and a Primary Downstream Service Flow. They give a default path for forwarded packets that aren't classified to any other Service Flow 👑Provisioned QPS: A QoS Parameter Set describing an envelope of service that a Service Flow is authorized to request admission within. All existing Service Flows must have a non-empty Provisioned QPS, so all SFs are considered "Provisioned" 🙈RF: Radio Frequency. In particular, this abbreviation refers to the radio frequencies for Cable Television (CATV).SCN: Service Class Name. A named set of QoS parameters. A Service Flow may or may not be tied to a single named Service Class. A Service Class has a QoS Parameter Set as an attribute, and that set is the default set of values for every Service Flow in the Service Class 🎀SID: Service ID. A 16-bit unsigned integer assigned by the CMTS to an Upstream Service Flow with a non-empty Active QoS Parameter Set 💖SF: Service Flow. A unidirectional stream of packets between the CM and the CMTS. SFs are characterized as upstream or downstream. The SF is the fundamental unit of service on a DOCSIS CATV network 🔥SFID: Service Flow ID. A 32-bit unsigned integer assigned by the CMTS to each Service Flow.Upstream: The direction from a subscriber CM to the head-end CMTS.
2. Overview 🌟
This MIB module gives you a set of objects that are required for managing DOCSIS 1.1 and 2.0 compliant Cable Modems (CM) and Cable Modem Termination Systems (CMTS). The spec is derived from the DOCSIS 2.0 Radio Frequency Interface specification [4]. Heads up: the referenced DOCSIS specs only require Cable Modems to process IPv4 customer traffic, so the design choices in this MIB module reflect that. Future versions of the DOCSIS standard are expected to require IPv6 support too 👀
The BCP 14 key words here are the ones you'll see in capitals below. They're interpreted as described in RFC 2119 [5], so read them as formal requirement words. 🫶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
2.1. Textual Conventions 🦋
The textual convention DocsIetfQosRfMacIfDirection is defined to show the direction of a packet classifier relative to an interface. It takes one of two values: downstream(1) or upstream(2) 💜
The textual convention DocsIetfQosBitRate matches the bits per second defined for QoS Parameter Sets in DOCSIS 1.1 and 2.0. This definition includes all the bits of the Ethernet MAC frame as transmitted on the RF network, starting with the Destination Address and ending with the Ethernet Frame Check Sequence (FCS). It does not include bits in the DOCSIS MAC header 🌈
2.2. MIB Organization ✨
Okay bestie, here's the family tree of the IPCDN QoS MIB module (DOCS-IETF-QOS-MIB) 🌳💖 Every table has its own entry and every entry has its own columns, so it's giving organized 💅
docsIetfQosMIB
docsIetfQosMIBObjects
docsIetfQosPktClassTable
docsIetfQosPktClassEntry
docsIetfQosPktClassId
docsIetfQosPktClassDirection
docsIetfQosPktClassPriority
docsIetfQosPktClassIpTosLow
docsIetfQosPktClassIpTosHigh
docsIetfQosPktClassIpTosMask
docsIetfQosPktClassIpProtocol
docsIetfQosPktClassInetAddressType
docsIetfQosPktClassInetSourceAddr
docsIetfQosPktClassInetSourceMask
docsIetfQosPktClassInetDestAddr
docsIetfQosPktClassInetDestMask
docsIetfQosPktClassSourcePortStart
docsIetfQosPktClassSourcePortEnd
docsIetfQosPktClassDestPortStart
docsIetfQosPktClassDestPortEnd
docsIetfQosPktClassDestMacAddr
docsIetfQosPktClassDestMacMask
docsIetfQosPktClassSourceMacAddr
docsIetfQosPktClassEnetProtocolType
docsIetfQosPktClassEnetProtocol
docsIetfQosPktClassUserPriLow
docsIetfQosPktClassUserPriHigh
docsIetfQosPktClassVlanId
docsIetfQosPktClassStateActive
docsIetfQosPktClassPkts
docsIetfQosPktClassBitMap
docsIetfQosParamSetTable
docsIetfQosParamSetEntry
docsIetfQosParamSetServiceClassName
docsIetfQosParamSetPriority
docsIetfQosParamSetMaxTrafficRate
docsIetfQosParamSetMaxTrafficBurst
docsIetfQosParamSetMinReservedRate
docsIetfQosParamSetMinReservedPkt
docsIetfQosParamSetActiveTimeout
docsIetfQosParamSetAdmittedTimeout
docsIetfQosParamSetMaxConcatBurst
docsIetfQosParamSetSchedulingType
docsIetfQosParamSetNomPollInterval
docsIetfQosParamSetTolPollJitter
docsIetfQosParamSetUnsolicitGrantSize
docsIetfQosParamSetNomGrantInterval
docsIetfQosParamSetTolGrantJitter
docsIetfQosParamSetGrantsPerInterval
docsIetfQosParamSetTosAndMask
docsIetfQosParamSetTosOrMask
docsIetfQosParamSetMaxLatency
docsIetfQosParamSetType
docsIetfQosParamSetRequestPolicyOct
docsIetfQosParamSetBitMap
docsIetfQosServiceFlowTable
docsIetfQosServiceFlowEntry
docsIetfQosServiceFlowId
docsIetfQosServiceFlowSID
docsIetfQosServiceFlowDirection
docsIetfQosServiceFlowPrimary
docsIetfQosServiceFlowStatsTable
docsIetfQosServiceFlowStatsEntry
docsIetfQosServiceFlowPkts
docsIetfQosServiceFlowOctets
docsIetfQosServiceFlowTimeCreated
docsIetfQosServiceFlowTimeActive
docsIetfQosServiceFlowPHSUnknowns
docsIetfQosServiceFlowPolicedDropPkts
docsIetfQosServiceFlowPolicedDelayPkts
docsIetfQosUpstreamStatsTable
docsIetfQosUpstreamStatsEntry
docsIetfQosSID
docsIetfQosUpstreamFragments
docsIetfQosUpstreamFragDiscards
docsIetfQosUpstreamConcatBursts
docsIetfQosDynamicServiceStatsTable
docsIetfQosDynamicServiceStatsEntry
docsIetfQosIfDirection
docsIetfQosDSAReqs
docsIetfQosDSARsps
docsIetfQosDSAAcks
docsIetfQosDSCReqs
docsIetfQosDSCRsps
docsIetfQosDSCAcks
docsIetfQosDSDReqs
docsIetfQosDSDRsps
docsIetfQosDynamicAdds
docsIetfQosDynamicAddFails
docsIetfQosDynamicChanges
docsIetfQosDynamicChangeFails
docsIetfQosDynamicDeletes
docsIetfQosDynamicDeleteFails
docsIetfQosDCCReqs
docsIetfQosDCCRsps
docsIetfQosDCCAcks
docsIetfQosDCCs
docsIetfQosDCCFails
docsIetfQosServiceFlowLogTable
docsIetfQosServiceFlowLogEntry
docsIetfQosServiceFlowLogIndex
docsIetfQosServiceFlowLogIfIndex
docsIetfQosServiceFlowLogSFID
docsIetfQosServiceFlowLogCmMac
docsIetfQosServiceFlowLogPkts
docsIetfQosServiceFlowLogOctets
docsIetfQosServiceFlowLogTimeDeleted
docsIetfQosServiceFlowLogTimeCreated
docsIetfQosServiceFlowLogTimeActive
docsIetfQosServiceFlowLogDirection
docsIetfQosServiceFlowLogPrimary
docsIetfQosServiceFlowLogServiceClassName
docsIetfQosServiceFlowLogPolicedDropPkts
docsIetfQosServiceFlowLogPolicedDelayPkts
docsIetfQosServiceFlowLogControl
docsIetfQosServiceClassTable
docsIetfQosServiceClassEntry
docsIetfQosServiceClassName
docsIetfQosServiceClassStatus
docsIetfQosServiceClassMaxTrafficRate
docsIetfQosServiceClassMaxTrafficBurst
docsIetfQosServiceClassMinReservedRate
docsIetfQosServiceClassMinReservedPkt
docsIetfQosServiceClassMaxConcatBurst
docsIetfQosServiceClassNomPollInterval
docsIetfQosServiceClassTolPollJitter
docsIetfQosServiceClassUnsolicitGrantSize
docsIetfQosServiceClassNomGrantInterval
docsIetfQosServiceClassTolGrantJitter
docsIetfQosServiceClassGrantsPerInterval
docsIetfQosServiceClassMaxLatency
docsIetfQosServiceClassActiveTimeout
docsIetfQosServiceClassAdmittedTimeout
docsIetfQosServiceClassSchedulingType
docsIetfQosServiceClassRequestPolicy
docsIetfQosServiceClassTosAndMask
docsIetfQosServiceClassTosOrMask
docsIetfQosServiceClassDirection
docsIetfQosServiceClassStorageType
docsIetfQosServiceClassDSCPOverwrite
docsIetfQosServiceClassPolicyTable
docsIetfQosServiceClassPolicyEntry
docsIetfQosServiceClassPolicyIndex
docsIetfQosServiceClassPolicyName
docsIetfQosServiceClassPolicyRulePriority
docsIetfQosServiceClassPolicyStatus
docsIetfQosServiceClassPolicyStorageType
docsIetfQosPHSTable
docsIetfQosPHSEntry
docsIetfQosPHSField
docsIetfQosPHSMask
docsIetfQosPHSSize
docsIetfQosPHSVerify
docsIetfQosPHSIndex
docsIetfQosCmtsMacToSrvFlowTable
docsIetfQosCmtsMacToSrvFlowEntry
docsIetfQosCmtsCmMac
docsIetfQosCmtsServiceFlowId
docsIetfQosCmtsIfIndexThis MIB module is organized as 11 tables 🎀 Most tables are implemented in both the CM and CMTS, but the docsIetfQosUpstreamStatsTable and docsIetfQosServiceFlowLogTable are implemented on the CMTS only 🫶
2.2.1. docsIetfQosPktClassTable 🦋
The docsIetfQosPktClassTable reports the Service Flow Classifiers implemented by the managed device 💜 It's indexed by the tuple { ifIndex, docsIetfQosServiceFlowId, docsIetfQosPktClassId }. The ifIndex corresponds to a CATV MAC interface. Each CATV MAC interface has a set of Service Flows identified with a docsIetfQosServiceFlowId value that is unique for that interface 🌸 Each Service Flow may have a number of packet classifiers that map packets to the flow. The ClassifierId for the classifier is unique only within a particular Service Flow, so no drama across flows 🙈
The semantics of packet classification are provided in [4]. Briefly, the DOCSIS MAC interface calls for matching packets based on values within the 802.2 (LLC), 802.3, IP, and/or UDP/TCP headers ✨ Packets that map more than one classifier are prioritized according to their docsIetfQosPktClassPriority values. The docsIetfQosServiceFlowId (an index object) indicates which Service Flow the packet is classified into 👑
The docsIetfQosPktClassTable is distinct from the docsDevIpFilterTable of [6] in that docsIetfQosPktClassTable is intended only to reflect the state of the Service Flow Classifiers. Service Flow Classifiers may be created only via a CM configuration file or from the Dynamic Service Addition (DSA) messages. For this reason, docsIetfQosPktClassTable is read-only 💀 It's not something you can edit, bestie, so don't even try 🙅
The docsDevIpFilterTable is intended for external policy-based administration of packet classifiers. See the section "Externally Administered Classification", below. That's the one for policy folks 🧚
2.2.2. docsIetfQosParamSetTable ✨
The docsIetfQosParamSetTable shows you the values of each QoS Parameter Set (QPS) as defined in Section C.2.2 of [4] 🎀
Okay, so a Service Flow (SF) has three different QPSs 💅: an "active" one, an "admitted" one, and a "provisioned" or "authorized" one. They nest inside each other like little Russian dolls 🪆, and it looks like this:
+---------------------+
| Provisioned |
| |
| +---------------+ |
| | Admitted | |
| | | |
| | +---------+ | |
| | | Active | | |
| | | | | |
| | +---------+ | |
| | | |
| +---------------+ |
| |
+---------------------+
Figure 1: QoS Parameter SetsThe Provisioned QPS is the maximum service envelope the SF is authorized for 🌸 The Admitted QPS is the set of services the SF has asked the DOCSIS RF network to admit, but which isn't active yet ⏳ This one is used during the two-phase process of IP Telephony/PacketCable Service Flow admission to admit the bandwidth for a bidirectional voice call while the far end is ringing 📞 Ringing can last up to four minutes, so the bandwidth gets reserved but not actually consumed during that time. Iconic, right? 😭 The Active QPS is the set of services the Service Flow is actually using right now 🦋
The DOCSIS v1.1 specification [4] defines what it means for one QPS envelope to be "within" another 🧠 Generally, an inner QPS counts as "within" an outer QPS when every QoS parameter asks for equal or fewer network resources than the outer one 💜
A QPS is also an attribute of a Service Class, not just a Service Flow 👑 A DOCSIS CM configuration file or DSA message can ask for a new SF and only give the Service Class Name. The CMTS "expands the macro" of that Service Class Name by filling in the Provisioned, Admitted, and/or Active QPSs of the Service Flow with the QPS of the Service Class Name 🔥 All the QPSs of a Service Flow have to be expansions of the same Service Class, and when that's true, the SF is said to "belong" to the Service Class 🫶 Changing a Service Class' QPS doesn't touch any Service Flow that was already expanded from that Service Class name, so no drama there 🙈 Only the CMTS implements docsIetfQosServiceClassTable 💅
For the full description and the theory of operation of DOCSIS 1.1 QoS, check out [4], section 8 📚
The docsIetfQosParamSetTable sets are indexed by { ifIndex, docsIetfQosServiceFlowId, docsIetfQosParamSetType }. The ifIndex tells you which particular "DOCSIS MAC Domain" you're looking at 🌈 The docsIetfQosServiceFlowId uniquely identifies a Service Flow on that MAC domain 🍓 And the docsIetfQosParamSetType tells you whether the row describes an active, admitted, or provisioned QoS Parameter Set 💖
The docsIetfQosParamSetTable is read-only, since it shows the QoS Parameter Set contents exactly as DOCSIS signaling defined them 🔒 Meanwhile, the docsIetfQosServiceClassTable is read-create, so managers can define a template of QoS Parameters that DOCSIS modems can reference when they build their QoS Parameter Sets ✨
2.2.2.1. Interoperation with DOCSIS 1.0
The DOCS-IF-MIB [7] specifies a docsIfQosProfileTable to describe the set of Class Of Service (COS) parameters tied to a COS "profile" 🎀 The docsIfCmServiceTable has one entry per SID, and it references this table with a docsIfCmServiceQosProfile number 💜
During DOCSIS 1.1 and 2.0 CM registration, a modem can register as operating with DOCSIS 1.0, DOCSIS 1.1, or DOCSIS 2.0 functionality 🧚 For simplicity, we call a modem registering with DOCSIS 1.0 functionality a "DOCSIS 1.0 modem," no matter what the modem can actually do 🫠
A CMTS or CM that supports DOCSIS 1.0, as well as DOCSIS 1.1 and/or DOCSIS 2.0, implements both the tables of [7] and the tables of this MIB module 🌸 The interop goal is that before modem registration, the DOCSIS 1.0 MIB [7] applies. After registration, either the DOCSIS 1.0 or the DOCSIS 1.1/2.0 MIB applies, depending on the mode the modem registered with 🦋 Here are the specific interop rules, bestie 👇
- When a CM initially ranges, the CM implements a row in the DOCS-IF-MIB docsIfCmServiceTable, and the CMTS implements a row in the DOCS-IF-MIB docsIfCmtsServiceTable for the default upstream Service ID (SID) used for pre-registration upstream traffic. For historical compatibility, a row may be created in the docsIfQosProfileTable with default values, which may be referenced by the docsIfCmServiceTable entries ✨
- Both a CMTS and CM implementing this MIB MUST NOT implement docsIetfQosParamSetTable or docsIetfQosServiceFlowTable rows until after the CM registers with DOCSIS 1.1 or 2.0 modem operation 🙅♀️
- When a modem registers with the CMTS as a "DOCSIS 1.1" or "DOCSIS 2.0" modem, any exclusively-referenced row in the DOCS-IF-MIB docsIfQosProfileTable that represents the modem's upstream QoS profile for pre-registration traffic MUST be removed. Multiply-referenced rows may remain 🧹 The docsIfCmServiceQosProfile object in the CM's row of docsIfCmServiceTable MUST be set to zero. The docsIfCmServiceTable row for the DOCSIS 1.1 or DOCSIS 2.0 modem keeps existing, and the various statistic objects in that row keep incrementing 📈 The CMTS should retain a docsIfCmtsServiceTable entry for the DOCSIS 1.1 or DOCSIS 2.0 CM 💅
- When a DOCSIS 1.1 or DOCSIS 2.0 modem registers, both the CMTS and the CM represent all Service Flows described in the modem configuration file in docsIetfQosParamSetTable and docsIetfQosServiceFlowTable 🌈
- DOCSIS 1.0 modems do not have entries in the DOCS-IETF-QOS-MIB 🍓
2.2.3. docsIetfQosServiceFlowTable
The docsIetfQosServiceFlowTable gives you read-only info about all the Service Flows the device knows about 👀 It's indexed by the combination of { ifIndex, dosQosServiceFlowId }, where ifIndex matches a CATV MAC interface and docsIetfQosServiceFlowId is the 32-bit integer the CMTS assigns for the MAC domain it controls 🔢 A CM usually has just one CATV MAC interface, while a CMTS can have several 💜 For how the ifIndex numbering works for DOCSIS devices, see [7] 📖
The table shows whether a given SF runs upstream or downstream, and whether it's the "primary" SF in that direction 🧚 The primary SF carries the traffic that isn't otherwise classified to any other SF in that direction 💖
2.2.4. docsIetfQosServiceFlowStatsTable
The docsIetfQosServiceFlowStatsTable provides statistics for all currently existing SFs known to the managed device 📊 It has the basic packet and octet counters, plus SF-specific stats like the time the flow was created and how many seconds it's been active ⏱️
The table also has objects you can use to fine-tune admission control decisions, namely the number of packets dropped or delayed because of QoS policing decisions the managed device enforces 🎯
The model for the Service Flows stats table is a Service Flow Classification function, followed by a Service Flow maximum rate Policing function for packets transmitted onto the DOCSIS RF network. It looks like this 👇
+----------+
+------------+ clsfy 1 -----+ | Per-SF | forwarded
Pkts | |-----------> | | Maximum |-> for DOCSIS
----->| Classify | clsfy 2 SF1 |--> | Rate | RF Network
| Function |-----------> | | Policing | transmission
| | -----+ | Function |
| | | |----+
| | | | |
| | +----------+ Dropped
+------------+ | ^
+----+ DelayedPackets headed for the DOCSIS RF network (upstream or downstream) get classified to a Service Flow first, by matching one of several possible classifiers tied to that Service Flow 🎀 The docsIetfQosPktClassPkts count includes every packet that matches the classifier, no matter where that packet ends up 📦
DOCSIS requires that each Service Flow be policed to keep a maximum rate of transmission 🚦 That happens by either dropping or delaying a packet on that Service Flow. The docsIetfQosServiceFlowPolicedDropPkts object counts the packets dropped by the policing function, and docsIetfQosServiceFlowPolicedDelayPkts counts the packets delayed but still forwarded 🫶 The docsIetfQosServiceFlowPkts object counts the total packets forwarded past the policing function, meant for eventual transmission onto the DOCSIS RF network 🌟 Packets can still get dropped later by other functions (for example, a transmit queue overflow on a DOCSIS hardware transmitter), but the docsIetfQos MIB per service-flow counters aren't affected by that 🙌
2.2.5. docsIetfQosUpstreamStatsTable
This table gives you statistics that are only measured at the CMTS in the upstream direction 🌈 That includes counts of fragmentation headers received, fragments discarded, and concatenation headers received 🦋
2.2.6. docsIetfQosDynamicServiceStatsTable ✨
okay bestie, this table is all about the stats 📊 on how the Dynamic Service state machines are doing (the ones from section 9.4 of [4]) 💅. It's read-only, so you can look but not touch 👀. Every DOCSIS MAC layer interface gets a set of 14 counters in each direction, which means each interface has one row for downstream stats and a second row for upstream stats 🦋.
Eight of those counters are DSx packet type counts, one for each of the eight DSx packet types 🎀. For example, the docsIetfQosDSAReqs object in the upstream row at the CMTS counts how many DSA-REQ messages the CMTS received from that interface 📥. The same object in the downstream row counts how many DSA-REQ messages the CMTS sent out on that interface 📤.
The other six counters per (interface, direction) combo count the successful and unsuccessful transactions that were initiated on that interface and direction 🌸. Like, the upstream docsIetfQosDynamicAdds on a CMTS is the number of successfully completed CM-initiated dynamic additions, because at the CMTS a CM-initiated DSA starts in the upstream direction 🙈. The downstream docsIetfQosDynamicAdds at a CMTS is the number of successful CMTS-initiated DSA transactions 💜.
Transactions can fail for a bunch of reasons, all listed in the state machines of section 9.4 🥲. Instead of a whole counter for every single reason, they get lumped into one count, e.g., docsIetfQosDynamicAddFails 🫶. This object also exists in both directions, so locally originated and remotely originated failures get counted separately 🔥.
If you need to figure out why a transaction failed, that takes vendor-specific queries and operation. These counters won't tell you the whole story 🕵️♀️.
2.2.7. docsIetfQosServiceFlowLogTable 📒
this table is a log of the Service Flows that no longer exist in the docsIetfQosServiceFlowTable 🗂️. It's meant to be polled regularly by traffic monitoring and billing agents 💸. It's only implemented at the CMTS, so the CM doesn't get this one 🙅♀️.
It's a chronological log of SF session stats, including the total count of packets and octets transferred on the SF 📦. It also has timestamps for the SF's creation time, its deletion time, and its number of active seconds ⏰. The active second count is how many seconds the SF had a non-empty Active QoS Parameter Set, which basically means it was eligible to pass data 🚦. For unicast SFs, it includes the CM MAC address tied to the flow for billing reference purposes 🧾.
The maximum number of log records a CMTS keeps, and how long a log record sticks around in the table, are both vendor-specific 🤷♀️. There's an explicit control object so the monitoring app can delete records it has already read 🧹, which is honestly very tidy of it 💖.
2.2.8. docsIetfQosServiceClassTable 🏷️
this table defines the Service Class Name and points to a QoS Parameter Set for each Service Class defined in a CMTS 💅. It's indexed by the Service Class Name string itself 🎀. It's read-create on a CMTS and not implemented in a CM 🙅♀️.
Each entry should define a template for flows in a given direction, either upstream or downstream 🦋. Some parameters here are direction-specific, so their values don't apply when the entry is used as a template for flows in the other direction 🙃. Lowkey a bit of a plot twist, but that's just how it goes 🌈.
2.2.9. docsIetfQosServiceClassPolicyTable 🧚
the docsIetfQosServiceClassPolicyTable can be referenced by the docsDevFilterPolicyTable of [6] to create a "policy" that classifies packets into a named Service Class 🪄. This is one way "external" entities (like an SNMP manager) can control how a packet gets classified for QoS 👑. Entries are indexed by a small-integer docsIetfQosServiceClassPolicyIndex 🔢. Each row gives you a Service Class Name and a Rule Priority ⭐.
A policy that references a row of this table is meant to send the packet out on a Service Flow "belonging" to that named Service Class 💌. For more on this, check out section 3, "Externally Administered Classification", below 📖.
This table is implemented on both the CM and the CMTS, and it's read-create on both 🫶.
2.2.10. docsIetfQosPHSTable 🌸
the Payload Header Suppression (PHS) feature from DOCSIS 1.1 and 2.0 lets packets swap out the unchanging bytes of their Ethernet, IP, and UDP headers for a one-byte index when they're sent over the cable network 🔥. This is honestly iconic for IP Telephony packets, because suppression can result in almost twice the number of calls supported within the same upstream channel 📞✨.
Each entry in the table matches a PHS Rule from section 8.4 of [4] 💅. The rules are identified by their matching Service Flow ID and docsIetfQosPktClassId 🆔. A PHS rule is tied to exactly one classifier, so the table is indexed by the tuple { ifIndex, docsIetfQosServiceFlowId, docsIetfQosPktClassId} 🧩.
This table is read-only, and it MUST be implemented on both the CM and the CMTS when PHS is supported 🔒. Not optional, bestie 💀.
2.2.11. docsIetfQosCmtsMacToSrvFlowTable 🗺️
the docsIetfQosCmtsMacToSrvFlowTable maps CM MAC addresses to the Service Flow IDs that are uniquely identified with each CM 🧭. External apps can gather stats on every packet flowing through a CM by finding the SFID of all of its flows, then collecting the packet and byte stats for each flow 📊. Main character energy for monitoring tools 💜.
Downstream multicast Service Flows don't show up in this table, because they aren't associated with just one CM 🌈.
3. Externally Administered Classification ✨
okay so DOCSIS 1.1 and 2.0 are literally iconic at classifying packets into Service Flows 💅 using the Service Flow Classifier table. Service Flow Classifiers can be made statically in the DOCSIS CM configuration file, or dynamically with Dynamic Service Addition (DSA) and Dynamic Service Change (DSC) DOCSIS MAC messages. 🦋
Several big issues came up around externally administered classification 😭. For example, should an external SNMP manager be allowed to create classification rows? One problem was coordinating classifier IDs, since that would need either separate classifier ID number spaces or objects to keep internal and external classifier ID assignments in sync. 🤔
The bigger problem was that external creation of SF Classifiers would need external applications to have "knowledge" of the individual Service Flow ID for each Service Flow. The committee felt really strongly that SFIDs should stay internal DOCSIS objects, and not get sent as part of protocol flows, like for IP packet telephony signaling. 🙅♀️ DOCSIS 1.1 brought in named Service Classes to make administration easier across a domain of CMs and CMTSs. What everyone actually wanted was to classify packets to a Service Class, not to one particular Service Flow. 💜
So the DOCSIS committee decided to reuse the already-defined IP Packet Filter Table [6] for external packet classification for QoS purposes. The docsDevIpPacketFilterTable has similar packet matching criteria to docsIetfQosPktClassTable, but it matches a packet to an arbitrary "policy set" instead of a specific Service Flow. One of the policies in that set then picks the Service Class of the SF the packet gets forwarded on. The docsIetfQosServiceClassPolicyTable in this MIB module defines the Service Class Name a packet is classified to. 🎀
Here's how external and internal classification fit together, bestie 👇
|
| Outbound Pkt
V
docsDevIpFilterTable------> docsDevFilterPolicyTable
| |
| V
| docsIetfQosServiceClassPolicyTable
| |
Pkt | ServiceClassName,|
| ServiceClassPolicyRulePriority|
V V
+--------------------------------------------------------+
| | DOCSIS MAC LAYER ENTITY | |
| | | Select |
| V | any |
| docsIetfQosPktClassTable <--------------| SFID Y |
| | | in SCN |
| | docsIetfQosPktClassPriority, | |
| | SFID X | |
| V V |
| +--------------------------------------------+ |
| | Select the SFID associated with the | |
| | higher of docsIetfQosPktClassPriority or | |
| | docsIetfQosServiceClassPolicyRulePriority | |
| +--------------------------------------------+ |
| | |
| V |
| | | | | |
| | | ... | | Service Flows |
| +----+ +----+ |
| SFID X SFID Y |
+--------------------------------------------------------+Figure 2: DOCSIS Packet Classification
Here's how an outgoing packet gets processed, step by step ✨:
- The packet is first checked for matches with rows of the docsDevIpFilterTable. If it matches, the matching row provides a docsDevFilterPolicyId integer.
- The docsDevFilterPolicyId indexes into one (or more) rows of docsDevFilterPolicyTable. Each row provides an arbitrary RowPointer (docsDevFilterPolicyPtr), which corresponds to a policy to be applied to the packet.
- This MIB module defines a docsIetfQosServiceClassPolicyTable whose entries may be pointed to by docsDevFilterPolicyPtr, so packets can be classified administratively to a named DOCSIS Service Class. The docsIetfQosServiceClassPolicyEntry gives a Service Class Name (SCN) as docsIetfQosServiceClassPolicyName, and a classification rule priority as docsIetfQosServiceClassPolicyRulePriority. These get submitted to the device's DOCSIS MAC Layer entity as a special form of the MAC_DATA.request primitive, as described in Section E.2.1 of [4].
- The MAC Layer selects an SFID ("Y") of an active Service Flow belonging to the named class, picking an SF arbitrarily if there's more than one. 🎲
- The packet then gets classified according to the docsIetfQosPktClassTable, which may classify it to a different SFID "X". The classifier also has a docsIetfQosPktClassPriority attached. 💅
- If the SCN-determined SFID and the classified SFID conflict, the greater of docsIetfQosPktClassPriority and docsIetfQosServiceClassPolicyRulePriority decides which SFID gets picked to forward the packet. 👑
A packet that doesn't match a docsIetfQosServiceClassPolicyEntry goes straight to the DOCSIS MAC layer, where the docsIetfQosPktClassTable picks the SID it gets forwarded on. 🧚
By convention (in [4]), the "internal" docsIetfQosPktClassPriority values should be in the range 64-191. The "external" priorities may be either in the range 192-255 to override internal classification, or in the range 0-63 to be overridden by internal classification. 🌈
This classification mechanism applies both upstream from the CM and downstream from the CMTS. 💖
4. DOCSIS and IPv4 Type-of-Service (ToS) Field 💖
The DOCSIS-IETF-QOS-MIB MIB module relies on the DOCSIS MAC layer protocols and uses objects that reflect the IPv4 Type-of-Service (ToS) octet as defined in [14]. These objects only apply to the DOCSIS access network. The past and current versions of the DOCSIS specifications this MIB module is defined for don't reflect Differentiated Services [9] on the DOCSIS access network. 🤷♀️
That said, with the right values set for these objects, the network operator can enforce Differentiated Services Per-hop Behaviors (PHBs) on the DOCSIS Access Network. They can also set up the modification of the DSCP for certain packet flows as they enter the metro network from the access network. Basically, this makes DOCSIS access network TOS marking compatible with the wider use of DSCP outside DOCSIS networks. ✨
Here's the tea 🫖: because the entire IPv4 TOS octet might be modifiable through that latter mechanism (thanks to the current MAC level DOCSIS protocols and CLI interface configuration), the DOCSIS network could be configured to modify the Explicit Congestion Notification (ECN) bits [10] of certain packets. 😳 The MIB module's design prevents this modification of the ECN bits. The MIB module prohibits modification of the TOS octet (read-only objects: docsIetfQosPktClassIpTosLow, docsIetfQosPktClassIpTosHigh docsIetfQosPktClassIpTosMask, docsIetfQosParamSetTosAndMask, docsIetfQosParamSetTosOrMask) and allows the DSCP field to be modified (read-create object: docsIetfQosServiceClassDSCPOverwrite). 🔒
5. Definitions 🎀
This MIB module refers to the SNMPv2-SMI [1] MIB module, SNMPv2-TC [2] MIB module, SNMPv2-CONF [3] MIB Module, DOCSIS RFI Specification SP-RFIv2.0-I06-040804 [4], INET-ADDRESS-MIB [8] MIB module, IF-MIB [11] MIB module, SNMP-FRAMEWORK-MIB [12] MIB module, and DIFFSERV-DSCP-TC [13] MIB module. 📚
DOCS-IETF-QOS-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
Counter32,
Unsigned32,
Counter64,
mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION,
MacAddress,
RowStatus,
TruthValue,
TimeStamp,
StorageType
FROM SNMPv2-TC
OBJECT-GROUP,
MODULE-COMPLIANCE
FROM SNMPv2-CONF
ifIndex,
InterfaceIndex
FROM IF-MIB
InetAddressType,
InetAddress,
InetPortNumber
FROM INET-ADDRESS-MIB
DscpOrAny
FROM DIFFSERV-DSCP-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB;
docsIetfQosMIB MODULE-IDENTITY
LAST-UPDATED "200601230000Z" -- January 23, 2006
ORGANIZATION "IETF IP over Cable Data Network (IPCDN)
Working Group"
CONTACT-INFO
"
Co-Author: Michael Patrick
Postal: Motorola BCS
111 Locke Drive
Marlborough, MA 01752-7214
U.S.A.
Phone: +1 508 786 7563
E-mail: michael.patrick@motorola.com
Co-Author: William Murwin
Postal: Motorola BCS
111 Locke Drive
Marlborough, MA 01752-7214
U.S.A.
Phone: +1 508 786 7594
E-mail: w.murwin@motorola.com
IETF IPCDN Working Group
General Discussion: ipcdn@ietf.org
Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn
Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn
Co-chairs: Richard Woundy, Richard_Woundy@cable.comcast.com
Jean-Francois Mule, jfm@cablelabs.com"
DESCRIPTION
"This is the management information for
Quality Of Service (QOS) for DOCSIS 1.1 and 2.0.
Copyright (C) The Internet Society (2006). This version of
this MIB module is part of RFC 4323; see the RFC itself for
full legal notices."
REVISION "200601230000Z" -- January 23, 2006
DESCRIPTION
"Initial version, published as RFC 4323."
::= { mib-2 127 }
--
-- Placeholder for notifications/traps.
--
docsIetfQosNotifications OBJECT IDENTIFIER ::= { docsIetfQosMIB 0 }
docsIetfQosMIBObjects OBJECT IDENTIFIER ::= { docsIetfQosMIB 1 }
-- Textual Conventions
DocsIetfQosRfMacIfDirection ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "Indicates a direction on an RF MAC interface.
The value downstream(1) is from Cable Modem
Termination System to Cable Modem.
The value upstream(2) is from Cable Modem to
Cable Modem Termination System."
SYNTAX INTEGER {
downstream(1),
upstream(2)
}
DocsIetfQosBitRate ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "The rate of traffic in unit of bits per second.
Used to specify traffic rate for QOS."
SYNTAX Unsigned32okay bestie, picking up right where we left off 🎀 first up is the scheduling type textual convention, which is how the CMTS decides what kind of scheduling service an upstream Service Flow gets ✨
DocsIetfQosSchedulingType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "The scheduling service provided by a CMTS for an
upstream Service Flow. If the parameter is omitted
from an upstream QOS Parameter Set, this object
takes the value of bestEffort (2). This parameter
must be reported as undefined (1) for downstream
QOS Parameter Sets."
SYNTAX INTEGER {
undefined (1),
bestEffort (2),
nonRealTimePollingService(3),
realTimePollingService(4),
unsolictedGrantServiceWithAD(5),
unsolictedGrantService(6)
}the vibe here is very "know your place" 💅 upstream flows get a real scheduling service, and downstream ones are just like, undefined (1), no drama 🧚
Now the packet classifier table 🦋 this is the ordered list of rules that a packet gets checked against. Each rule is one row, and a matching rule hands back a Service Flow ID. Every rule in a classifier needs to match, so it's giving strict bouncer 😭
-----------------------------------------------------------------------
--
-- Packet Classifier Table
--
docsIetfQosPktClassTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsIetfQosPktClassEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table describes the packet classification
configured on the CM or CMTS.
The model is that a packet either received
as input from an interface or transmitted
for output on an interface may be compared
against an ordered list of rules pertaining to
the packet contents. Each rule is a row of this
table. A matching rule provides a Service Flow
ID to which the packet is classified.
All rules need to match for a packet to match
a classifier.
The objects in this row correspond to a set of
Classifier Encoding parameters in a DOCSIS
MAC management message. The
docsIetfQosPktClassBitMap indicates which
particular parameters were present in the
classifier as signaled in the DOCSIS message.
If the referenced parameter was not present
in the signaled DOCSIS 1.1 and 2.0 Classifier, the
corresponding object in this row reports a
value as specified in the DESCRIPTION section."
::= { docsIetfQosMIBObjects 1 }
docsIetfQosPktClassEntry OBJECT-TYPE
SYNTAX DocsIetfQosPktClassEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in this table provides a single packet
classifier rule. The index ifIndex is an ifType
of docsCableMaclayer(127)."
INDEX {
ifIndex,
docsIetfQosServiceFlowId,
docsIetfQosPktClassId
}
::= { docsIetfQosPktClassTable 1 }the index is the real power move here 👑 each entry is keyed by the ifIndex, the Service Flow ID, and the classifier ID all together
Next up is the sequence that lays out every column in one entry 🌸 this is where all the classifier fields live, from the TOS stuff to the MAC addresses to the VLAN ID, and it's a whole lot 😭
DocsIetfQosPktClassEntry ::= SEQUENCE {
docsIetfQosPktClassId Unsigned32,
docsIetfQosPktClassDirection DocsIetfQosRfMacIfDirection,
docsIetfQosPktClassPriority Integer32,
docsIetfQosPktClassIpTosLow OCTET STRING,
docsIetfQosPktClassIpTosHigh OCTET STRING,
docsIetfQosPktClassIpTosMask OCTET STRING,
docsIetfQosPktClassIpProtocol Integer32,
docsIetfQosPktClassInetAddressType InetAddressType,
docsIetfQosPktClassInetSourceAddr InetAddress,
docsIetfQosPktClassInetSourceMask InetAddress,
docsIetfQosPktClassInetDestAddr InetAddress,
docsIetfQosPktClassInetDestMask InetAddress,
docsIetfQosPktClassSourcePortStart InetPortNumber,
docsIetfQosPktClassSourcePortEnd InetPortNumber,
docsIetfQosPktClassDestPortStart InetPortNumber,
docsIetfQosPktClassDestPortEnd InetPortNumber,
docsIetfQosPktClassDestMacAddr MacAddress,
docsIetfQosPktClassDestMacMask MacAddress,
docsIetfQosPktClassSourceMacAddr MacAddress,
docsIetfQosPktClassEnetProtocolType INTEGER,
docsIetfQosPktClassEnetProtocol Integer32,
docsIetfQosPktClassUserPriLow Integer32,
docsIetfQosPktClassUserPriHigh Integer32,
docsIetfQosPktClassVlanId Integer32,
docsIetfQosPktClassStateActive TruthValue,
docsIetfQosPktClassPkts Counter64,
docsIetfQosPktClassBitMap BITS
}now we go column by column, starting with the classifier ID 🦋
docsIetfQosPktClassId OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Index assigned to packet classifier entry by
the CMTS, which is unique per Service Flow."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.3.2"
::= { docsIetfQosPktClassEntry 1 }
docsIetfQosPktClassDirection OBJECT-TYPE
SYNTAX DocsIetfQosRfMacIfDirection
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Indicates the direction to which the classifier
is applied."
::= { docsIetfQosPktClassEntry 2 }
docsIetfQosPktClassPriority OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The value specifies the order of evaluation
of the classifiers.
The higher the value, the higher the priority.
The value of 0 is used as default in
provisioned Service Flows Classifiers.
The default value of 64 is used for dynamic
Service Flow Classifiers.
If the referenced parameter is not present
in a classifier, this object reports the default
value as defined above."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.3.5"
::= { docsIetfQosPktClassEntry 3 }priority is basically the evaluation order, and higher means it goes first 💖 provisioned flows default to 0, and dynamic ones default to 64 ✨
Now the TOS fields 🌈 these come from the old IP TOS octet from RFC 791, which has been upgraded to the DSField from RFC 3260 and the ECN field from RFC 3168. The DOCSIS spec still treats it as an 8-bit octet for classification, so that's what these objects do.
docsIetfQosPktClassIpTosLow OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The low value of a range of TOS byte values.
If the referenced parameter is not present
in a classifier, this object reports the value
of 0.
The IP TOS octet, as originally defined in RFC 791,
has been superseded by the 6-bit Differentiated
Services Field (DSField, RFC 3260) and the 2-bit
Explicit Congestion Notification Field (ECN field,
RFC 3168). This object is defined as an 8-bit
octet as per the DOCSIS Specification
for packet classification."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.1"
::= { docsIetfQosPktClassEntry 4 }
docsIetfQosPktClassIpTosHigh OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The 8-bit high value of a range of TOS byte
values.
If the referenced parameter is not present
in a classifier, this object reports the
value of 0.
The IP TOS octet as originally defined in RFC 791
has been superseded by the 6-bit Differentiated
Services Field (DSField, RFC 3260) and the 2-bit
Explicit Congestion Notification Field (ECN field,
RFC 3168). This object is defined as an 8-bit
octet as defined by the DOCSIS Specification
for packet classification."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.1"
::= { docsIetfQosPktClassEntry 5 }
docsIetfQosPktClassIpTosMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The mask value is bitwise ANDed with TOS byte
in an IP packet, and this value is used for
range checking of TosLow and TosHigh.
If the referenced parameter is not present
in a classifier, this object reports the value
of 0.
The IP TOS octet as originally defined in RFC 791
has been superseded by the 6-bit Differentiated
Services Field (DSField, RFC 3260) and the 2-bit
Explicit Congestion Notification Field (ECN field,
RFC 3168). This object is defined as an 8-bit
octet per the DOCSIS Specification for packet
classification."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.1"
::= { docsIetfQosPktClassEntry 6 }the mask gets ANDed with the TOS byte, and then it's used for the range check against TosLow and TosHigh 🦋 very bitwise, very iconic 💅
Last few objects for this chunk: the IP protocol, the address type, and the source address 🫶
docsIetfQosPktClassIpProtocol OBJECT-TYPE
SYNTAX Integer32 (0..258)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object indicates the value of the IP
Protocol field required for IP packets to match
this rule.
The value 256 matches traffic with any IP Protocol
value. The value 257 by convention matches both TCP
and UDP.
If the referenced parameter is not present
in a classifier, this object reports the value
of 258."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.2"
::= { docsIetfQosPktClassEntry 7 }
docsIetfQosPktClassInetAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The type of the Internet address for
docsIetfQosPktClassInetSourceAddr,
docsIetfQosPktClassInetSourceMask,
docsIetfQosPktClassInetDestAddr, and
docsIetfQosPktClassInetDestMask.
If the referenced parameter is not present
in a classifier, this object reports the value of
ipv4(1)."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.3"
::= { docsIetfQosPktClassEntry 8 }
docsIetfQosPktClassInetSourceAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object specifies the value of the IP
Source Address required for packets to match
this rule.
An IP packet matches the rule when the packet
IP Source Address bitwise ANDed with the
docsIetfQosPktClassInetSourceMask value equals the
docsIetfQosPktClassInetSourceAddr value.
The address type of this object is specified by
docsIetfQosPktClassInetAddressType.
If the referenced parameter is not present
in a classifier, this object reports the value of
'00000000'H."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.3"
::= { docsIetfQosPktClassEntry 9 }so the protocol field can be 256 for any protocol or 257 for TCP and UDP together, and the address type defaults to ipv4(1) 🌸 we're cooking, bestie 🔥
Okay bestie, the mask for the source address is next and it's giving precision 💅✨ It decides which bits of the source address actually get checked, so it's basically the filter's little pair of glasses 👓🦋
docsIetfQosPktClassInetSourceMask OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object specifies which bits of a packet's
IP Source Address are compared to match
this rule.
An IP packet matches the rule when the packet
source address bitwise ANDed with the
docsIetfQosPktClassInetSourceMask value equals the
docsIetfQosIpPktClassInetSourceAddr value.
The address type of this object is specified by
docsIetfQosPktClassInetAddressType.
If the referenced parameter is not present
in a classifier, this object reports the value of
'FFFFFFFF'H."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.4"
::= { docsIetfQosPktClassEntry 10 }Next up is the destination address, and honestly it's the mirror of the source one 🪞🌸 The matching works the same way, just on the other end of the packet, so the vibe is "same energy, different side" 💜
docsIetfQosPktClassInetDestAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object specifies the value of the IP
Destination Address required for packets to match
this rule.
An IP packet matches the rule when the packet
IP Destination Address bitwise ANDed with the
docsIetfQosPktClassInetDestMask value
equals the docsIetfQosPktClassInetDestAddr value.
The address type of this object is specified by
docsIetfQosPktClassInetAddressType.
If the referenced parameter is not present
in a classifier, this object reports the value of
'00000000'H."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.5"
::= { docsIetfQosPktClassEntry 11 }Now the destination mask, which pairs up with the dest address like best friends 🧚💖
docsIetfQosPktClassInetDestMask OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object specifies which bits of a packet's
IP Destination Address are compared to
match this rule.
An IP packet matches the rule when the packet
destination address bitwise ANDed with the
docsIetfQosPktClassInetDestMask value equals the
docsIetfQosIpPktClassInetDestAddr value.
The address type of this object is specified by
docsIetfQosPktClassInetAddressType.
If the referenced parameter is not present
in a classifier, this object reports the value of
'FFFFFFFF'H."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.6"
::= { docsIetfQosPktClassEntry 12 }Ports are next, and ngl this part is so satisfying 🎀 The source port range is an inclusive low-to-high window, and if the parameter isn't set, it defaults to the full span from 0 up to 65535 🌈
docsIetfQosPktClassSourcePortStart OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object specifies the low-end inclusive
range of TCP/UDP source port numbers to which
a packet is compared. This object is irrelevant
for non-TCP/UDP IP packets.
If the referenced parameter is not present
in a classifier, this object reports the value
of 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.7"
::= { docsIetfQosPktClassEntry 13 }
docsIetfQosPktClassSourcePortEnd OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object specifies the high-end inclusive
range of TCP/UDP source port numbers to which
a packet is compared. This object is irrelevant
for non-TCP/UDP IP packets.
If the referenced parameter is not present
in a classifier, this object reports the value of
65535."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.8"
::= { docsIetfQosPktClassEntry 14 }Quick heads-up: the source port objects say they don't matter for packets that aren't TCP or UDP. So if the packet isn't one of those, these fields just sit there looking pretty 🙈
Now the destination ports, same idea but on the receiving side 🍓
docsIetfQosPktClassDestPortStart OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object specifies the low-end inclusive
range of TCP/UDP destination port numbers to
which a packet is compared.
If the referenced parameter is not present
in a classifier, this object reports the value
of 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.9"
::= { docsIetfQosPktClassEntry 15 }
docsIetfQosPktClassDestPortEnd OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object specifies the high-end inclusive
range of TCP/UDP destination port numbers to which
a packet is compared.
If the referenced parameter is not present
in a classifier, this object reports the value of
65535."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.5.10"
::= { docsIetfQosPktClassEntry 16 }MAC addresses are up next, and they're giving Ethernet-level main character energy 🌟 The destination MAC address and its mask work together the same way the IP ones do ✨
docsIetfQosPktClassDestMacAddr OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An Ethernet packet matches an entry when its
destination MAC address bitwise ANDed with
docsIetfQosPktClassDestMacMask equals the value of
docsIetfQosPktClassDestMacAddr.
If the referenced parameter is not present
in a classifier, this object reports the value of
'000000000000'H."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.6.1"
::= { docsIetfQosPktClassEntry 17 }
docsIetfQosPktClassDestMacMask OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An Ethernet packet matches an entry when its
destination MAC address bitwise ANDed with
docsIetfQosPktClassDestMacMask equals the value of
docsIetfQosPktClassDestMacAddr.
If the referenced parameter is not present
in a classifier, this object reports the value of
'000000000000'H."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.6.1"
::= { docsIetfQosPktClassEntry 18 }Source MAC is next, and this one is the most straightforward of the bunch 💅 It's a plain equality check, no masks involved 🫶
docsIetfQosPktClassSourceMacAddr OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An Ethernet packet matches this entry when its
source MAC address equals the value of
this object.
If the referenced parameter is not present
in a classifier, this object reports the value of
'FFFFFFFFFFFF'H."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.6.2"
::= { docsIetfQosPktClassEntry 19 }Now we're at the Ethernet protocol type, and it's lowkey the most layered one yet 🧁 It has five possible values, and each one changes how the protocol field gets read 🔥
docsIetfQosPktClassEnetProtocolType OBJECT-TYPE
SYNTAX INTEGER {
none(0),
ethertype(1),
dsap(2),
mac(3),
all(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object indicates the format of the layer 3
protocol ID in the Ethernet packet. A value of
none(0) means that the rule does not use the
layer 3 protocol type as a matching criteria.
A value of ethertype(1) means that the rule
applies only to frames that contain an
EtherType value. Ethertype values are contained
in packets using the Dec-Intel-Xerox (DIX)
encapsulation or the RFC1042 Sub-Network Access
Protocol (SNAP) encapsulation formats.
A value of dsap(2) means that the rule applies
only to frames using the IEEE802.3
encapsulation format with a Destination Service
Access Point (DSAP) other
than 0xAA (which is reserved for SNAP).
A value of mac(3) means that the rule applies
only to MAC management messages for MAC management
messages.
A value of all(4) means that the rule matches
all Ethernet packets.
If the Ethernet frame contains an 802.1P/Q Tag
header (i.e., EtherType 0x8100), this object
applies to the embedded EtherType field within
the 802.1P/Q header.
If the referenced parameter is not present in a
classifier, this object reports the value of 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.6.3"
::= { docsIetfQosPktClassEntry 20 }And the last object in this part is the Ethernet protocol value, which changes its whole personality depending on the type we just looked at 🦋 It's a 0 to 65535 number, and what it means depends entirely on which protocol type is chosen 👑
docsIetfQosPktClassEnetProtocol OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "If docsIetfQosEthPktClassProtocolType is none(0),
this object is ignored when considering whether
a packet matches the current rule.
If dosQosPktClassEnetProtocolType is ethertype(1),
this object gives the 16-bit value of the
EtherType that the packet must match in order to
match the rule.
If docsIetfQosPktClassEnetProtocolType is dsap(2),
the lower 8 bits of this object's value must match
the DSAP byte of the packet in order to match the
rule.
If docsIetfQosPktClassEnetProtocolType is mac(3),
the lower 8 bits of this object's value represent a
lower bound (inclusive) of MAC management message
type codes matched, and the upper 8 bits represent
the upper bound (inclusive) of matched MAC message
type codes. Certain message type codes are
excluded from matching, as specified in the
reference.
If the Ethernet frame contains an 802.1P/Q Tag
header (i.e., EtherType 0x8100), this object applies
to the embedded EtherType field within the 802.1P/Q
header.
If the referenced parameter is not present in the
classifier, the value of this object is reported
as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.6.3"
::= { docsIetfQosPktClassEntry 21 }Okay bestie, the 802.1P/Q VLAN tag stuff is up first, and it's giving tiny tagged frames with big feelings 🎀✨ Each tag holds a 3-bit priority and a 12-bit VLAN number, so these objects are all about matching on those bits 💅
docsIetfQosPktClassUserPriLow OBJECT-TYPE
SYNTAX Integer32 (0..7)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object applies only to Ethernet frames
using the 802.1P/Q tag header (indicated with
EtherType 0x8100). Such frames include a 16-bit
Tag that contains a 3-bit Priority field and
a 12-bit VLAN number.
Tagged Ethernet packets must have a 3-bit
Priority field within the range of
docsIetfQosPktClassPriLow to
docsIetfQosPktClassPriHigh in order to match this
rule.
If the referenced parameter is not present in the
classifier, the value of this object is reported
as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.7.1"
::= { docsIetfQosPktClassEntry 22 }
docsIetfQosPktClassUserPriHigh OBJECT-TYPE
SYNTAX Integer32 (0..7)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object applies only to Ethernet frames
using the 802.1P/Qtag header (indicated with
EtherType 0x8100). Such frames include a 16-bit
Tag that contains a 3-bit Priority field and
a 12-bit VLAN number.
Tagged Ethernet packets must have a 3-bit
Priority field within the range of
docsIetfQosPktClassPriLow to
docsIetfQosPktClassPriHigh in order to match this
rule.
If the referenced parameter is not present in the
classifier, the value of this object is reported
as 7."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.7.1"
::= { docsIetfQosPktClassEntry 23 }
docsIetfQosPktClassVlanId OBJECT-TYPE
SYNTAX Integer32 (0 | 1..4094)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object applies only to Ethernet frames
using the 802.1P/Q tag header.
Tagged packets must have a VLAN Identifier that
matches the value in order to match the rule.
If the referenced parameter is not present in the
classifier, the value of this object is reported
as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.7.2"
::= { docsIetfQosPktClassEntry 24 }Next up is the on/off switch for classifiers 🦋 docsIetfQosPktClassStateActive tells you whether the classifier is allowed to sort packets into a Service Flow, and if the parameter isn't in the classifier, it's reported as true(1). Then we've got the packet counter, which is lowkey iconic 📊
docsIetfQosPktClassStateActive OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object indicates whether or not the classifier
is enabled to classify packets to a Service Flow.
If the referenced parameter is not present in the
classifier, the value of this object is reported
as true(1)."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.3.6"
::= { docsIetfQosPktClassEntry 25 }
docsIetfQosPktClassPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object counts the number of packets that have
been classified using this entry. This
includes all packets delivered to a Service Flow
maximum rate policing function, whether or not that
function drops the packets.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosPktClassEntry 26 }The docsIetfQosPktClassBitMap is a little checklist 💜 Every bit tells you whether a certain parameter was actually sent in the DOCSIS message that made the classifier. BITS are encoded most significant bit first, so bits 6 and 7 set come out as '030000'H. Iykyk 🙈
docsIetfQosPktClassBitMap OBJECT-TYPE
SYNTAX BITS { -- Reference SP-RFIv2.0-I06-040804
rulePriority(0), -- Appendix C.2.1.3.4
activationState(1), -- Appendix C.2.1.3.6
ipTos(2), -- Appendix C.2.1.5.1
ipProtocol(3), -- Appendix C.2.1.5.2
ipSourceAddr(4), -- Appendix C.2.1.5.3
ipSourceMask(5), -- Appendix C.2.1.5.4
ipDestAddr(6), -- Appendix C.2.1.5.5
ipDestMask(7), -- Appendix C.2.1.5.6
sourcePortStart(8), -- Appendix C.2.1.5.7
sourcePortEnd(9), -- Appendix C.2.1.5.8
destPortStart(10), -- Appendix C.2.1.5.9
destPortEnd(11), -- Appendix C.2.1.5.10
destMac(12), -- Appendix C.2.1.6.1
sourceMac(13), -- Appendix C.2.1.6.2
ethertype(14), -- Appendix C.2.1.6.3
userPri(15), -- Appendix C.2.1.7.1
vlanId(16) -- Appendix C.2.1.7.2
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates which parameter encodings
were actually present in the DOCSIS packet
classifier encoding signaled in the DOCSIS message
that created or modified the classifier. Note that
Dynamic Service Change messages have replace
semantics, so that all non-default parameters must
be present whether the classifier is being created
or changed.
A bit of this object is set to 1 if the parameter
indicated by the comment was present in the
classifier encoding, and to 0 otherwise.
Note that BITS are encoded most significant bit
first, so that if, for example, bits 6 and 7 are
set, this object is encoded as the octet string
'030000'H."
::= { docsIetfQosPktClassEntry 27 }Now we switch over to the QoS Parameter Set Table 🌸 This is where the DOCSIS 1.1 and 2.0 QoS parameters live, and DOCSIS 1.0 service profiles are not in here, so don't go looking for them 🙅♀️
--
-- QOS Parameter Set Table
--
docsIetfQosParamSetTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsIetfQosParamSetEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table describes the set of DOCSIS 1.1 and 2.0
QOS parameters defined in a managed device.
The ifIndex index specifies a DOCSIS MAC Domain.
The docsIetfQosServiceFlowId index specifies a
particular Service Flow.
The docsIetfQosParamSetType index indicates whether
the active, admitted, or provisioned QOS Parameter
Set is being described by the row.
Only the QOS Parameter Sets of DOCSIS 1.1 and 2.0
Service Flows are represented in this table.
DOCSIS 1.0 QOS service profiles are not
represented in this table.
Each row corresponds to a DOCSIS QOS Parameter Set
as signaled via DOCSIS MAC management messages.
Each object in the row corresponds to one or
part of one DOCSIS 1.1 Service Flow Encoding.
The docsIetfQosParamSetBitMap object in the row
indicates which particular parameters were signaled
in the original registration or dynamic service
request message that created the QOS Parameter Set.
In many cases, even if a QOS Parameter Set parameter
was not signaled, the DOCSIS specification calls
for a default value to be used. That default value
is reported as the value of the corresponding object
in this row.
Many objects are not applicable, depending on
the Service Flow direction or upstream scheduling
type. The object value reported in this case
is specified in the DESCRIPTION clause."
::= { docsIetfQosMIBObjects 2 }
docsIetfQosParamSetEntry OBJECT-TYPE
SYNTAX DocsIetfQosParamSetEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A unique set of QOS parameters."
INDEX {
ifIndex, docsIetfQosServiceFlowId, docsIetfQosParamSetType
}
::= { docsIetfQosParamSetTable 1 }
DocsIetfQosParamSetEntry ::= SEQUENCE {
docsIetfQosParamSetServiceClassName SnmpAdminString,
docsIetfQosParamSetPriority Integer32,
docsIetfQosParamSetMaxTrafficRate DocsIetfQosBitRate,
docsIetfQosParamSetMaxTrafficBurst Unsigned32,
docsIetfQosParamSetMinReservedRate DocsIetfQosBitRate,
docsIetfQosParamSetMinReservedPkt Integer32,
docsIetfQosParamSetActiveTimeout Integer32,
docsIetfQosParamSetAdmittedTimeout Integer32,
docsIetfQosParamSetMaxConcatBurst Integer32,
docsIetfQosParamSetSchedulingType DocsIetfQosSchedulingType,
docsIetfQosParamSetNomPollInterval Unsigned32,
docsIetfQosParamSetTolPollJitter Unsigned32,
docsIetfQosParamSetUnsolicitGrantSize Integer32,
docsIetfQosParamSetNomGrantInterval Unsigned32,
docsIetfQosParamSetTolGrantJitter Unsigned32,
docsIetfQosParamSetGrantsPerInterval Integer32,
docsIetfQosParamSetTosAndMask OCTET STRING,
docsIetfQosParamSetTosOrMask OCTET STRING,
docsIetfQosParamSetMaxLatency Unsigned32,
docsIetfQosParamSetType INTEGER,
docsIetfQosParamSetRequestPolicyOct OCTET STRING,
docsIetfQosParamSetBitMap BITS
}
docsIetfQosParamSetServiceClassName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Refers to the Service Class Name from which the
parameter set values were derived.
If the referenced parameter is not present in the
corresponding DOCSIS QOS Parameter Set, the default
value of this object is a zero-length string."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.3.4"
::= { docsIetfQosParamSetEntry 1 }
docsIetfQosParamSetPriority OBJECT-TYPE
SYNTAX Integer32 (0..7)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The relative priority of a Service Flow.
Higher numbers indicate higher priority.
This priority should only be used to differentiate
Service Flow from identical parameter sets.
If the referenced parameter is not present in the
corresponding DOCSIS QOS Parameter Set, the default
value of this object is 0. If the parameter is
not applicable, the reported value is 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.1"
::= { docsIetfQosParamSetEntry 2 }Okay bestie, the maxTrafficRate is basically the speed limit for a Service Flow 🚗💨 💖
docsIetfQosParamSetMaxTrafficRate OBJECT-TYPE
SYNTAX DocsIetfQosBitRate
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Maximum sustained traffic rate allowed for this
Service Flow in bits/sec. Must count all MAC frame
data PDU from the bytes following the MAC header
HCS to the end of the CRC. The number of bytes
forwarded is limited during any time interval.
The value 0 means no maximum traffic rate is
enforced. This object applies to both upstream and
downstream Service Flows.
If the referenced parameter is not present in the
corresponding DOCSIS QOS Parameter Set, the default
value of this object is 0. If the parameter is
not applicable, it is reported as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.2"
::= { docsIetfQosParamSetEntry 3 }Next up is maxTrafficBurst, and it's giving bucket vibes 🪣✨ It's the token bucket size in bytes, and it works together with the rate above to figure out the max sustained traffic rate. Iconic teamwork 👯♀️
docsIetfQosParamSetMaxTrafficBurst OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the token bucket size in bytes
for this parameter set. The value is calculated
from the byte following the MAC header HCS to
the end of the CRC. This object is applied in
conjunction with docsIetfQosParamSetMaxTrafficRate
to calculate maximum sustained traffic rate.
If the referenced parameter is not present in the
corresponding DOCSIS QOS Parameter Set, the default
value of this object for scheduling types
bestEffort (2), nonRealTimePollingService(3),
and realTimePollingService(4) is 3044.
If this parameter is not applicable, it is reported
as 0.
"
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.3"
::= { docsIetfQosParamSetEntry 4 }Now minReservedRate 🌸 This is the guaranteed minimum, so bandwidth is only reserved if it's not 0. Zero means nothing gets set aside, no cap, no drama 💅
docsIetfQosParamSetMinReservedRate OBJECT-TYPE
SYNTAX DocsIetfQosBitRate
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the guaranteed minimum rate in
bits/sec for this parameter set. The value is
calculated from the byte following the MAC
header HCS to the end of the CRC. The default
value of 0 means that no bandwidth is reserved.
If the referenced parameter is not present in the
corresponding DOCSIS QOS Parameter Set, the default
value of this object is 0. If the parameter
is not applicable, it is reported as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.4"
::= { docsIetfQosParamSetEntry 5 }minReservedPkt is next, and ngl it's a little bit of a plot twist 🙈 It's an assumed minimum packet size, and the default here is implementation dependent, so the CMTS reports whatever it's using while the CM reports 0 in that case. Read the room, babe 👀
docsIetfQosParamSetMinReservedPkt OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies an assumed minimum packet size in
bytes for which the
docsIetfQosParamSetMinReservedRate will be
provided. The value is calculated from the byte
following the MAC header HCS to the end of the
CRC.
If the referenced parameter is omitted from a
DOCSIS QOS parameter set, the default value is
CMTS implementation dependent. In this case, the
CMTS reports the default value it is using, and the
CM reports a value of 0. If the referenced
parameter is not applicable to the direction or
scheduling type of the Service Flow, both CMTS and
CM report this object's value as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.5"
::= { docsIetfQosParamSetEntry 6 }activeTimeout 💀 This is the countdown for how long resources can sit unused on an active flow before the CMTS signals that the active and admitted sets are null. Zero means forever, which is very "never leave the party" energy 🎉
docsIetfQosParamSetActiveTimeout OBJECT-TYPE
SYNTAX Integer32 (0..65535)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the maximum duration in seconds that
resources remain unused on an active service
flow before CMTS signals that both active and
admitted parameters set are null. The default
value of 0 signifies an infinite amount of time.
If the referenced parameter is not present in the
corresponding DOCSIS QOS Parameter Set, the default
value of this object is 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.6"
::= { docsIetfQosParamSetEntry 7 }admittedTimeout 🦋 Same vibe as the active one, but this time it's about how long resources can hang out in the admitted state before they get released. The default is 200 when it's missing, and that DEFVAL line is the receipt 🧾
docsIetfQosParamSetAdmittedTimeout OBJECT-TYPE
SYNTAX Integer32 (0..65535)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the maximum duration in seconds that
resources remain in admitted state before
resources must be released.
The value of 0 signifies an infinite amount
of time.
If the referenced parameter is not present in the
corresponding DOCSIS QOS Parameter Set, the
default value of this object is 200.
"
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.5.7"
DEFVAL { 200 }
::= { docsIetfQosParamSetEntry 8 }maxConcatBurst 🧚 This one measures the max concatenated burst in bytes for an upstream flow, and it's counted from the FC byte of the Concatenation MAC Header all the way to the last CRC byte of the last concatenated frame, inclusive. Long name, big energy 🌈
docsIetfQosParamSetMaxConcatBurst OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the maximum concatenated burst in
bytes that an upstream Service Flow is allowed.
The value is calculated from the FC byte of the
Concatenation MAC Header to the last CRC byte in
of the last concatenated MAC frame, inclusive.
The value of 0 specifies no maximum burst.
If the referenced parameter is not present in the
corresponding DOCSIS QOS Parameter Set, the default
value of this object for scheduling types
bestEffort(2), nonRealTimePollingService(3), and
realTimePollingService(4) is 1522. If the parameter
is not applicable, this object's value is reported
as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.1"
::= { docsIetfQosParamSetEntry 9 }schedulingType 👑 This is the upstream scheduling service for upstream flows. If it's missing on an upstream flow, the default is bestEffort(2). Downstream sets just report undefined(1), so they're not really in the scheduling game 🙃
docsIetfQosParamSetSchedulingType OBJECT-TYPE
SYNTAX DocsIetfQosSchedulingType
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the upstream scheduling service used for
upstream Service Flow.
If the referenced parameter is not present in the
corresponding DOCSIS QOS Parameter Set of an
upstream Service Flow, the default value of this
object is bestEffort(2). For QOS parameter sets of
downstream Service Flows, this object's value is
reported as undefined(1)."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.2"
::= { docsIetfQosParamSetEntry 10 }nomPollInterval ⏱️ This is the nominal gap in microseconds between unicast request opportunities. It only applies to a few upstream scheduling types, and it's mandatory for realTimePollingService(4). Everything else is a mix of CMTS defaults and "report what you're using," so it's a whole group project 🫶
docsIetfQosParamSetNomPollInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the nominal interval in microseconds
between successive unicast request
opportunities on an upstream Service Flow.
This object applies only to upstream Service Flows
with DocsIetfQosSchedulingType of value
nonRealTimePollingService(3),
realTimePollingService(4), and
unsolictedGrantServiceWithAD(5). The parameter is
mandatory for realTimePollingService(4). If the
parameter is omitted with
nonRealTimePollingService(3), the CMTS uses an
implementation-dependent value. If the parameter
is omitted with unsolictedGrantServiceWithAD(5),
the CMTS uses as a default value the value of the
Nominal Grant Interval parameter. In all cases,
the CMTS reports the value it is using when the
parameter is applicable. The CM reports the
signaled parameter value if it was signaled,
and 0 otherwise.
If the referenced parameter is not applicable to
the direction or scheduling type of the
corresponding DOCSIS QOS Parameter Set, both
CMTS and CM report this object's value as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.4"
::= { docsIetfQosParamSetEntry 11 }tolPollJitter 🌀 This is how far the unicast request interval can drift from the nominal periodic schedule, measured in microseconds. It only matters for upstream flows with realTimePollingService(4) or unsolictedGrantServiceWithAD(5). Jitter is the villain of every good schedule, honestly 😭
docsIetfQosParamSetTolPollJitter OBJECT-TYPE
SYNTAX Unsigned32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the maximum amount of time in
microseconds that the unicast request interval
may be delayed from the nominal periodic
schedule on an upstream Service Flow.
This parameter is applicable only to upstream
Service Flows with a DocsIetfQosSchedulingType of
realTimePollingService(4) or
unsolictedGrantServiceWithAD(5).
If the referenced parameter is applicable but not
present in the corresponding DOCSIS QOS Parameter
Set, the CMTS uses an implementation-dependent
value and reports the value it is using.
The CM reports a value of 0 in this case.
If the parameter is not applicable to the
direction or upstream scheduling type of the
Service Flow, both CMTS and CM report this
object's value as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.5"
::= { docsIetfQosParamSetEntry 12 }Last one in this batch: unsolicitGrantSize 🎁 This is the unsolicited grant size in bytes, counted from the Frame Control byte to the end of the MAC frame. It's only for upstream flows with unsolicitedGrantServicewithAD(5) or unsolicitedGrantService(6), and when it applies it's mandatory, so CMTS and CM both report the signaled value. It's giving full commitment 💖
docsIetfQosParamSetUnsolicitGrantSize OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the unsolicited grant size in bytes.
The grant size includes the entire MAC frame
data PDU from the Frame Control byte to the end
of the MAC frame.
The referenced parameter is applicable only
for upstream flows with a DocsIetfQosSchedulingType
of unsolicitedGrantServicewithAD(5) or
unsolicitedGrantService(6), and it is mandatory
when applicable. Both CMTS and CM report
the signaled value of the parameter in this
case.
If the referenced parameter is not applicable to
the direction or scheduling type of the
corresponding DOCSIS QOS Parameter Set, both
CMTS and CM report this object's value as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.6"
::= { docsIetfQosParamSetEntry 13 }okay bestie, we're picking right back up with the grant stuff ✨ these next objects are all about how often and how big the upstream grants are 🫶
docsIetfQosParamSetNomGrantInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the nominal interval in microseconds
between successive data grant opportunities
on an upstream Service Flow.
The referenced parameter is applicable only
for upstream flows with a DocsIetfQosSchedulingType
of unsolicitedGrantServicewithAD(5) or
unsolicitedGrantService(6), and it is mandatory
when applicable. Both CMTS and CM report the
signaled value of the parameter in this case.
If the referenced parameter is not applicable to
the direction or scheduling type of the
corresponding DOCSIS QOS Parameter Set, both
CMTS and CM report this object's value as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.7"
::= { docsIetfQosParamSetEntry 14 }okay so NomGrantInterval is the nominal gap in microseconds between grant opportunities 🦋 It only matters for upstream flows that use unsolicitedGrantServicewithAD(5) or unsolicitedGrantService(6), and when it applies it's mandatory 💅 If it doesn't apply, both the CMTS and the CM just report 0 🙈
docsIetfQosParamSetTolGrantJitter OBJECT-TYPE
SYNTAX Unsigned32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the maximum amount of time in
microseconds that the transmission opportunities
may be delayed from the nominal periodic schedule.
The referenced parameter is applicable only
for upstream flows with a DocsIetfQosSchedulingType
of unsolicitedGrantServicewithAD(5) or
unsolicitedGrantService(6), and it is mandatory
when applicable. Both CMTS and CM report the
signaled value of the parameter in this case.
If the referenced parameter is not applicable to
the direction or scheduling type of the
corresponding DOCSIS QOS Parameter Set, both
CMTS and CM report this object's value as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.8"
::= { docsIetfQosParamSetEntry 15 }ngl TolGrantJitter is the wiggle room 🧚 It's the max time in microseconds that transmission opportunities can slip away from the nominal periodic schedule. Same rules as before: same scheduling types, same mandatory-when-applicable vibe, and a 0 report when it doesn't apply 🎀
docsIetfQosParamSetGrantsPerInterval OBJECT-TYPE
SYNTAX Integer32 (0..127)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the number of data grants per Nominal
Grant Interval
(docsIetfQosParamSetNomGrantInterval).
The referenced parameter is applicable only
for upstream flows with a DocsIetfQosSchedulingType
of unsolicitedGrantServicewithAD(5) or
unsolicitedGrantService(6), and it is mandatory
when applicable. Both CMTS and CM report the
signaled value of the parameter in this case.
If the referenced parameter is not applicable to
the direction or scheduling type of the
corresponding DOCSIS QOS Parameter Set, both
CMTS and CM report this object's value as 0."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.9"
::= { docsIetfQosParamSetEntry 16 }GrantsPerInterval is simply how many data grants you get per Nominal Grant Interval 🍓 It's an Integer32 between 0 and 127, and it follows the exact same applicability rules as the two above 💖
docsIetfQosParamSetTosAndMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the AND mask for the IP TOS byte for
overwriting IP packet's TOS value. The IP packet
TOS byte is bitwise ANDed with
docsIetfQosParamSetTosAndMask, and the result is
bitwise ORed with docsIetfQosParamSetTosORMask and
the result is written to the IP packet TOS byte.
A value of 'FF'H for docsIetfQosParamSetTosAndMask
and a value of '00'H for
docsIetfQosParamSetTosOrMask means that the IP
Packet TOS byte is not overwritten.
This combination is reported if the referenced
parameter is not present in a QOS Parameter Set.
The IP TOS octet as originally defined in RFC 791
has been superseded by the 6-bit Differentiated
Services Field (DSField, RFC 3260) and the 2-bit
Explicit Congestion Notification Field (ECN field,
RFC 3168). Network operators SHOULD avoid
specifying values of docsIetfQosParamSetTosAndMask
and docsIetfQosParamSetTosORMask that would result
in the modification of the ECN bits.
In particular, operators should not use values of
docsIetfQosParamSetTosAndMask that have either of
the least-significant two bits set to 0. Similarly,
operators should not use values of
docsIetfQosParamSetTosORMask that have either of
the least-significant two bits set to 1.
Even though this object is only enforced by the
Cable Modem Termination System (CMTS),
Cable Modems MUST report the value as signaled in
the referenced parameter."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.10;
RFC 3168, The Addition of Explicit Congestion
Notification (ECN) to IP;
RFC 3260, New Terminology and Clarifications for
Diffserv."
::= { docsIetfQosParamSetEntry 17 }okay TosAndMask is the big drama one, so pay attention 👑 It's the AND mask for the IP TOS byte. The packet's TOS byte gets ANDed with this mask, then ORed with the OR mask, and the result gets written back 😭 An 'FF'H AND mask plus a '00'H OR mask means the byte just stays as it is 🦋
The TOS octet from RFC 791 has been replaced by the 6-bit DSField (RFC 3260) and the 2-bit ECN field (RFC 3168), so operators are told to steer clear of values that touch the ECN bits 🙅♀️ The description also calls out the least-significant two bits for both masks, and it says this object is only enforced by the CMTS, while Cable Modems still have to report the signaled value 🎀
💀 ECN bits are not a toy, bestie. Don't let your masks mess with them.
docsIetfQosParamSetTosOrMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the OR mask for the IP TOS byte.
See the description of docsIetfQosParamSetTosAndMask
for further details.
The IP TOS octet as originally defined in RFC 791
has been superseded by the 6-bit Differentiated
Services Field (DSField, RFC 3260) and the 2-bit
Explicit Congestion Notification Field (ECN field,
RFC 3168). Network operators SHOULD avoid
specifying values of docsIetfQosParamSetTosAndMask
and docsIetfQosParamSetTosORMask that would result
in the modification of the ECN bits."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.10;
RFC 3168, The Addition of Explicit Congestion
Notification (ECN) to IP;
RFC 3260, New Terminology and Clarifications for
Diffserv."
::= { docsIetfQosParamSetEntry 18 }TosOrMask is the OR half of that combo 🌸 Read the TosAndMask section for the full story, because this one just points back there 💖 It has the same DSField and ECN warning too, so no sneaky ECN edits 🫶
docsIetfQosParamSetMaxLatency OBJECT-TYPE
SYNTAX Unsigned32
UNITS "microseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies the maximum latency between the
reception of a packet by the CMTS on its NSI
and the forwarding of the packet to the RF
interface. A value of 0 signifies no maximum
latency is enforced. This object only applies to
downstream Service Flows.
If the referenced parameter is not present in the
corresponding downstream DOCSIS QOS Parameter Set,
the default value is 0. This parameter is
not applicable to upstream DOCSIS QOS Parameter
Sets, and its value is reported as 0 in this case."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.7.1"
::= { docsIetfQosParamSetEntry 19 }MaxLatency is the max time in microseconds between the CMTS getting a packet on its NSI and forwarding it to the RF interface ⏱️ A 0 means no max latency is enforced ✨ It only applies to downstream Service Flows, and if it's missing from the downstream QoS Parameter Set the default is 0 too 🧚 For upstream sets it's always reported as 0 🌈
docsIetfQosParamSetType OBJECT-TYPE
SYNTAX INTEGER {
active (1),
admitted (2),
provisioned (3)
}
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Defines the type of the QOS parameter set defined
by this row. active(1) indicates the Active QOS
parameter set, describing the service currently
being provided by the DOCSIS MAC domain to the
Service Flow. admitted(2) indicates the Admitted
QOS Parameter Set, describing services reserved by
the DOCSIS MAC domain for use by the service
flow. provisioned (3) describes the QOS Parameter
Set defined in the DOCSIS CM Configuration file for
the Service Flow."
REFERENCE "SP-RFIv2.0-I06-040804, 8.1.5"
::= { docsIetfQosParamSetEntry 20 }Type is how we tell the three QoS Parameter Sets apart 🎀 active(1) is the one currently being given to the Service Flow, admitted(2) is the one reserved for it, and provisioned(3) is the one from the CM Configuration file 💅 It's not accessible directly, so it's just there to label the row 💜
docsIetfQosParamSetRequestPolicyOct OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
-- A 32-bit mask represented most significant byte
-- first. The 32-bit integer represented in this
-- manner equals the binary value of the referenced
-- integer parameter of the DOCSIS RFI
-- specification.
-- The BITS syntax is not used in order to avoid
-- the confusion caused by different bit-numbering
-- conventions.
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Specifies which transmit interval opportunities
the CM omits for upstream transmission requests and
packet transmissions. This object takes its
default value for downstream Service Flows.
Unless otherwise indicated, a bit value of 1 means
that a CM must not use that opportunity for
upstream transmission.
If bit 0 is the least significant bit of the
least significant (4th) octet, and if bit number
is increased with significance, the bit definitions
are defined as follows:
broadcastReqOpp(0):
all CMs broadcast request opportunities
priorityReqMulticastReq(1):
priority request multicast request
opportunities
reqDataForReq(2):
request/data opportunities for requests
reqDataForData(3):
request/data opportunities for data
piggybackReqWithData(4):
piggyback requests with data
concatenateData(5):
concatenate data
fragmentData(6):
fragment data
suppresspayloadheaders(7):
suppress payload headers
dropPktsExceedUGSize(8):
A value of 1 means that the Service Flow must
drop packets that do not fit in the Unsolicited
Grant size.
If the referenced parameter is not present in
a QOS Parameter Set, the value of this object is
reported as '00000000'H."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.3"
::= { docsIetfQosParamSetEntry 21 }RequestPolicyOct is a 4-byte mask 🍓 Each bit says which transmit opportunities the CM skips for upstream requests and transmissions, and bit 0 is the least significant bit of the 4th octet 🌈 A 1 means the CM must not use that opportunity for upstream transmission, and it's also what you get as '00000000'H if the parameter isn't in the QoS Parameter Set 🦋
The bit list runs from broadcastReqOpp(0) all the way to dropPktsExceedUGSize(8), which is the one that says drop packets that don't fit the Unsolicited Grant size 🙈 It's giving very specific, very important, and I'm obsessed 🔥
okay bestie, the bitmap is where it gets so good 💖 each bit is basically a little checkbox for a QoS parameter, and the comments tell you exactly which spec section it came from 🦋
docsIetfQosParamSetBitMap OBJECT-TYPE
-- Each bit corresponds to a parameter
-- from SP-RFI-v1.1-I10-037030,
-- Appendix C in the indicated
SYNTAX BITS { -- section number.
trafficPriority(0), -- C.2.2.5.1
maxTrafficRate(1), -- C.2.2.5.2
maxTrafficBurst(2), -- C.2.2.5.3
minReservedRate(3), -- C.2.2.5.4
minReservedPkt(4), -- C.2.2.5.5
activeTimeout(5), -- C.2.2.5.6
admittedTimeout(6), -- C.2.2.5.7
maxConcatBurst(7), -- C.2.2.6.1
schedulingType(8), -- C.2.2.6.2
requestPolicy(9), -- C.2.2.6.3
nomPollInterval(10), -- C.2.2.6.4
tolPollJitter(11), -- C.2.2.6.5
unsolicitGrantSize(12), -- C.2.2.6.6
nomGrantInterval(13), -- C.2.2.6.7
tolGrantJitter(14), -- C.2.2.6.8
grantsPerInterval(15), -- C.2.2.6.9
tosOverwrite(16), -- C.2.2.6.10
maxLatency(17) -- C.2.2.7.1
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object indicates the set of QOS Parameter
Set parameters actually signaled in the
DOCSIS registration or dynamic service request
message that created or modified the QOS Parameter
Set. A bit is set to 1 when the parameter described
by the indicated reference section is present
in the original request.
Note that when Service Class names are expanded,
the registration or dynamic response message may
contain parameters as expanded by the CMTS based
on a stored service class. These expanded
parameters are not indicated by a 1 bit in this
object.
Note that even though some QOS Parameter Set
parameters may not be signaled in a message
(so that the paramater's bit in this object is 0),
the DOCSIS specification requires that default
values be used. These default values are reported
as the corresponding object's value in the row.
Note that BITS objects are encoded most
significant bit first. For example, if bits
1 and 16 are set, the value of this object
is the octet string '400080'H."
::= { docsIetfQosParamSetEntry 22 }ngl the DESCRIPTION is doing the most here 😭 it's basically saying a bit flips to 1 only if that parameter actually showed up in the original request, and when a service class gets expanded, those parameters don't get a 1 bit 🙈 the default values still apply even when a bit is 0, and bits are encoded most significant bit first (so bits 1 and 16 give you '400080'H, iykyk) 🧚
Next up is the Service Flow Table, and it's giving main character energy 👑 it's the list of all the DOCSIS-QOS Service Flows on a managed device, and every row is keyed by ifIndex plus the Service Flow ID 🌸
--
-- Service Flow Table
--
docsIetfQosServiceFlowTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsIetfQosServiceFlowEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table describes the set of DOCSIS-QOS
Service Flows in a managed device."
::= { docsIetfQosMIBObjects 3 }
docsIetfQosServiceFlowEntry OBJECT-TYPE
SYNTAX DocsIetfQosServiceFlowEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Describes a Service Flow.
An entry in the table exists for each
Service Flow ID. The ifIndex is an
ifType of docsCableMaclayer(127)."
INDEX {
ifIndex,
docsIetfQosServiceFlowId
}
::= { docsIetfQosServiceFlowTable 1 }
DocsIetfQosServiceFlowEntry ::= SEQUENCE {
docsIetfQosServiceFlowId Unsigned32,
docsIetfQosServiceFlowSID Unsigned32,
docsIetfQosServiceFlowDirection DocsIetfQosRfMacIfDirection,
docsIetfQosServiceFlowPrimary TruthValue
}
docsIetfQosServiceFlowId OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An index assigned to a Service Flow by CMTS."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.3.2"
::= { docsIetfQosServiceFlowEntry 1 }
docsIetfQosServiceFlowSID OBJECT-TYPE
SYNTAX Unsigned32 (0..16383)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Service Identifier (SID) assigned to an
admitted or active Service Flow. This object
reports a value of 0 if a Service ID is not
associated with the Service Flow. Only active
or admitted upstream Service Flows will have a
Service ID (SID)."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.3.3"
::= { docsIetfQosServiceFlowEntry 2 }
docsIetfQosServiceFlowDirection OBJECT-TYPE
SYNTAX DocsIetfQosRfMacIfDirection
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The direction of the Service Flow."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.1/2"
::= { docsIetfQosServiceFlowEntry 3 }
docsIetfQosServiceFlowPrimary OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Object reflects whether Service Flow is the primary
or a secondary Service Flow.
A primary Service Flow is the default Service Flow
for otherwise unclassified traffic and all MAC
messages."
REFERENCE "SP-RFIv2.0-I06-040804, Section 8.1 "
::= { docsIetfQosServiceFlowEntry 4 }
--
-- Service Flow Stats Table
--
docsIetfQosServiceFlowStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsIetfQosServiceFlowStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table describes statistics associated with the
Service Flows in a managed device."
::= { docsIetfQosMIBObjects 4 }
docsIetfQosServiceFlowStatsEntry OBJECT-TYPE
SYNTAX DocsIetfQosServiceFlowStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Describes a set of Service Flow statistics.
An entry in the table exists for each
Service Flow ID. The ifIndex is an
ifType of docsCableMaclayer(127)."
INDEX {
ifIndex,
docsIetfQosServiceFlowId
}
::= { docsIetfQosServiceFlowStatsTable 1 }
DocsIetfQosServiceFlowStatsEntry ::= SEQUENCE {
docsIetfQosServiceFlowPkts Counter64,
docsIetfQosServiceFlowOctets Counter64,
docsIetfQosServiceFlowTimeCreated TimeStamp,
docsIetfQosServiceFlowTimeActive Counter32,
docsIetfQosServiceFlowPHSUnknowns Counter32,
docsIetfQosServiceFlowPolicedDropPkts Counter32,
docsIetfQosServiceFlowPolicedDelayPkts Counter32
}
docsIetfQosServiceFlowPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION "For outgoing Service Flows, this object counts the
number of Packet Data PDUs forwarded to this
Service Flow. For incoming upstream CMTS service
flows, this object counts the number of Packet
Data PDUs actually received on the Service Flow
identified by the SID for which the packet was
scheduled. CMs not classifying downstream packets
may report this object's value as 0 for downstream
Service Flows. This object does not count
MAC-specific management messages.
Particularly for UGS flows, packets sent on the
primary Service Flow in violation of the UGS grant
size should be counted only by the instance of this
object that is associated with the primary service
flow.
Unclassified upstream user data packets (i.e., non-
MAC-management) forwarded to the primary upstream
Service Flow should be counted by the instance of
this object that is associated with the primary
service flow.
This object does include packets counted by
docsIetfQosServiceFlowPolicedDelayPkts, but does not
include packets counted by
docsIetfQosServiceFlowPolicedDropPkts
and docsIetfQosServiceFlowPHSUnknowns.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosServiceFlowStatsEntry 1 }
docsIetfQosServiceFlowOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of octets from the byte after the MAC
header HCS to the end of the CRC for all packets
counted in the docsIetfQosServiceFlowPkts object for
this row. Note that this counts the octets after
payload header suppression and before payload
header expansion have been applied.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosServiceFlowStatsEntry 2 }
docsIetfQosServiceFlowTimeCreated OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The value of sysUpTime when the service flow
was created."
::= { docsIetfQosServiceFlowStatsEntry 3 }
docsIetfQosServiceFlowTimeActive OBJECT-TYPE
SYNTAX Counter32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of seconds that the service flow
has been active.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosServiceFlowStatsEntry 4 }
docsIetfQosServiceFlowPHSUnknowns OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "For incoming upstream CMTS service flows, this
object counts the number of packets received
with an unknown payload header suppression index.
The service flow is identified by the SID for which
the packet was scheduled.
On a CM, only this object's instance for the primary
downstream service flow counts packets received with
an unknown payload header suppression index. All
other downstream service flows on CM report this
objects value as 0.
All outgoing service flows report this object's
value as 0.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosServiceFlowStatsEntry 5 }the stats table is where the counters live, and honestly the DESCRIPTIONs are so detailed they're basically a whole vibe 🍓 the packet and octet counters have their own rules about what gets counted (and what doesn't), and every counter's last discontinuity points at the same ifCounterDiscontinuityTime 🌈
Okay bestie, so the policed drop counter is for outgoing service flows, and it's basically the tally of Packet Data PDUs that got dropped because of two specific reasons 💅 First, excessive delay while enforcing the Maximum Sustained Traffic Rate. Second, UGS packets that went over the Unsolicited Grant Size under a Request/Transmission policy that says they get dropped. Anything dropped for some other reason gets counted somewhere else, in ifOutDiscards for the interface 🫶 It reads 0 for incoming flows, so no drama there.
docsIetfQosServiceFlowPolicedDropPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "For outgoing service flows, this object counts the
number of Packet Data PDUs classified to this
service flow dropped due to:
(1) implementation-dependent excessive delay
while enforcing the Maximum Sustained
Traffic Rate; or
(2) UGS packets dropped due to exceeding the
Unsolicited Grant Size with a
Request/Transmission policy that requires
such packets to be dropped.
Classified packets dropped due to other reasons
must be counted in ifOutDiscards for the interface
of this service flow. This object reports 0 for
incoming service flows.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosServiceFlowStatsEntry 6 }Next up is the delayed packets counter 🦋 This one only tracks outgoing packets that got delayed to keep the Maximum Sustained Traffic Rate in check. For UGS flows it's always 0, since that rate doesn't apply to them, and it's also 0 for incoming flows.
docsIetfQosServiceFlowPolicedDelayPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object counts only outgoing packets delayed in
order to maintain the Maximum Sustained Traffic
Rate. This object will always report a value of 0
for UGS flows because the Maximum Sustained Traffic
Rate does not apply. This object is 0 for incoming
service flows.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosServiceFlowStatsEntry 7 }
--
-- Upstream Service Flow Stats Table (CMTS ONLY)
--
docsIetfQosUpstreamStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsIetfQosUpstreamStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table describes statistics associated with
upstream service flows. All counted frames must
be received without a Frame Check Sequence (FCS)
error."
::= { docsIetfQosMIBObjects 5 }
docsIetfQosUpstreamStatsEntry OBJECT-TYPE
SYNTAX DocsIetfQosUpstreamStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Describes a set of upstream service flow
statistics. An entry in the table exists for each
upstream Service Flow in a managed device.
The ifIndex is an ifType of
docsCableMaclayer(127)."
INDEX {
ifIndex,
docsIetfQosSID
}
::= { docsIetfQosUpstreamStatsTable 1 }
DocsIetfQosUpstreamStatsEntry ::= SEQUENCE {
docsIetfQosSID Unsigned32,
docsIetfQosUpstreamFragments Counter32,
docsIetfQosUpstreamFragDiscards Counter32,
docsIetfQosUpstreamConcatBursts Counter32
}
docsIetfQosSID OBJECT-TYPE
SYNTAX Unsigned32 (1..16383)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Identifies a service ID for an admitted or active
upstream service flow."
::= { docsIetfQosUpstreamStatsEntry 1 }
docsIetfQosUpstreamFragments OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of fragmentation headers received on an
upstream service flow, regardless of whether
the fragment was correctly reassembled into a
valid packet.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosUpstreamStatsEntry 2 }
docsIetfQosUpstreamFragDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of upstream fragments discarded and not
assembled into a valid upstream packet.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosUpstreamStatsEntry 3 }
docsIetfQosUpstreamConcatBursts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of concatenation headers received on an
upstream service flow.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosUpstreamStatsEntry 4 }Okay so the upstream stats table is CMTS only, and it's the one for upstream service flows ✨ Every counted frame has to come in without an FCS error, and each row is keyed by the ifIndex plus the service ID (SID). The SID is a 1..16383 number for an admitted or active upstream flow 🌸 The fragment counters count fragmentation headers and fragments that got discarded, and there's a concatenation burst counter too. 🔥
Last bit of this chunk is the dynamic service stats table, which is giving main character energy 👑 It has two rows for each DOCSIS MAC layer interface, one for upstream and one for downstream. The direction meaning depends on whether the device is the CMTS or the CM, so read that DESCRIPTION carefully, it's a whole vibe 🙈
--
-- Dynamic Service Stats Table
--
docsIetfQosDynamicServiceStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsIetfQosDynamicServiceStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table describes statistics associated with the
Dynamic Service Flows in a managed device."
::= { docsIetfQosMIBObjects 6 }
docsIetfQosDynamicServiceStatsEntry OBJECT-TYPE
SYNTAX DocsIetfQosDynamicServiceStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Describes a set of dynamic service flow statistics.
Two entries exist for each DOCSIS MAC layer
interface for the upstream and downstream
direction. On the CMTS, the downstream direction
row indicates messages transmitted or transactions
originated by the CMTS. The upstream direction row
indicates messages received or transaction
originated by the CM. On the CM, the downstream
direction row indicates messages received or
transactions originated by the CMTS. The upstream
direction row indicates messages transmitted by
the CM or transactions originated by the CM.
The ifIndex is an ifType of
docsCableMaclayer(127)."
INDEX {
ifIndex,
docsIetfQosIfDirection
}
::= { docsIetfQosDynamicServiceStatsTable 1 }
DocsIetfQosDynamicServiceStatsEntry ::= SEQUENCE {
docsIetfQosIfDirection DocsIetfQosRfMacIfDirection,
docsIetfQosDSAReqs Counter32,
docsIetfQosDSARsps Counter32,
docsIetfQosDSAAcks Counter32,
docsIetfQosDSCReqs Counter32,
docsIetfQosDSCRsps Counter32,
docsIetfQosDSCAcks Counter32,
docsIetfQosDSDReqs Counter32,
docsIetfQosDSDRsps Counter32,
docsIetfQosDynamicAdds Counter32,
docsIetfQosDynamicAddFails Counter32,
docsIetfQosDynamicChanges Counter32,
docsIetfQosDynamicChangeFails Counter32,
docsIetfQosDynamicDeletes Counter32,
docsIetfQosDynamicDeleteFails Counter32,
docsIetfQosDCCReqs Counter32,
docsIetfQosDCCRsps Counter32,
docsIetfQosDCCAcks Counter32,
docsIetfQosDCCs Counter32,
docsIetfQosDCCFails Counter32
}
docsIetfQosIfDirection OBJECT-TYPE
SYNTAX DocsIetfQosRfMacIfDirection
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The direction of interface."
::= { docsIetfQosDynamicServiceStatsEntry 1 }
docsIetfQosDSAReqs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of Dynamic Service Addition Requests,
including retries.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 2 }
docsIetfQosDSARsps OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of Dynamic Service Addition Responses,
including retries.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 3 }
docsIetfQosDSAAcks OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of Dynamic Service Addition
Acknowledgements, including retries.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 4 }
docsIetfQosDSCReqs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of Dynamic Service Change Requests,
including retries.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 5 }
docsIetfQosDSCRsps OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of Dynamic Service Change Responses,
including retries.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 6 }
docsIetfQosDSCAcks OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of Dynamic Service Change
Acknowledgements, including retries.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 7 }
docsIetfQosDSDReqs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of Dynamic Service Delete Requests,
including retries.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 8 }
docsIetfQosDSDRsps OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of Dynamic Service Delete Responses,
including retries.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 9 }Okay bestie, the dynamic transaction counters are next and they are SO organized 🎀💅
docsIetfQosDynamicAdds OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of successful Dynamic Service Addition
transactions.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 10 }
docsIetfQosDynamicAddFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of failed Dynamic Service Addition
transactions.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 11 }
docsIetfQosDynamicChanges OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of successful Dynamic Service Change
transactions.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 12 }
docsIetfQosDynamicChangeFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of failed Dynamic Service Change
transactions.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 13 }
docsIetfQosDynamicDeletes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of successful Dynamic Service Delete
transactions.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 14 }
docsIetfQosDynamicDeleteFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of failed Dynamic Service Delete
transactions.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 15 }Now the DCC counters 🦋 These are the Dynamic Channel Change ones, and a few of them only light up on specific rows. Check the direction notes in each description, because they matter 👀
docsIetfQosDCCReqs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of Dynamic Channel Change Request
messages traversing an interface. This count
is nonzero only on downstream direction rows.
This count should include the number of retries.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex
that indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 16 }
docsIetfQosDCCRsps OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of Dynamic Channel Change Response
messages traversing an interface. This count is
nonzero only on upstream direction rows. This count
should include the number of retries.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 17 }
docsIetfQosDCCAcks OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of Dynamic Channel Change Acknowledgement
messages traversing an interface. This count
is nonzero only on downstream direction rows.
This count should include the number of retries.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 18 }
docsIetfQosDCCs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of successful Dynamic Channel Change
transactions. This count is nonzero only on
downstream direction rows.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 19 }
docsIetfQosDCCFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of failed Dynamic Channel Change
transactions. This count is nonzero only on
downstream direction rows.
This counter's last discontinuity is the
ifCounterDiscontinuityTime for the same ifIndex that
indexes this object."
::= { docsIetfQosDynamicServiceStatsEntry 20 }Last stop for this part: the Service Flow Log table 🧚 This one is CMTS ONLY, and it's basically a diary of Service Flows that have already been disconnected. Main character archive energy 📚✨
--
-- Service Flow Log Table (CMTS ONLY)
--
docsIetfQosServiceFlowLogTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsIetfQosServiceFlowLogEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table contains a log of the disconnected
Service Flows in a managed device."
::= { docsIetfQosMIBObjects 7 }
docsIetfQosServiceFlowLogEntry OBJECT-TYPE
SYNTAX DocsIetfQosServiceFlowLogEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The information regarding a single disconnected
service flow."
INDEX {
docsIetfQosServiceFlowLogIndex
}
::= { docsIetfQosServiceFlowLogTable 1 }
DocsIetfQosServiceFlowLogEntry ::= SEQUENCE {
docsIetfQosServiceFlowLogIndex Unsigned32,
docsIetfQosServiceFlowLogIfIndex InterfaceIndex,
docsIetfQosServiceFlowLogSFID Unsigned32,
docsIetfQosServiceFlowLogCmMac MacAddress,
docsIetfQosServiceFlowLogPkts Counter64,
docsIetfQosServiceFlowLogOctets Counter64,
docsIetfQosServiceFlowLogTimeDeleted TimeStamp,
docsIetfQosServiceFlowLogTimeCreated TimeStamp,
docsIetfQosServiceFlowLogTimeActive Counter32,
docsIetfQosServiceFlowLogDirection DocsIetfQosRfMacIfDirection,
docsIetfQosServiceFlowLogPrimary TruthValue,
docsIetfQosServiceFlowLogServiceClassName SnmpAdminString,
docsIetfQosServiceFlowLogPolicedDropPkts Counter32,
docsIetfQosServiceFlowLogPolicedDelayPkts Counter32,
docsIetfQosServiceFlowLogControl INTEGER
}
docsIetfQosServiceFlowLogIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Unique index for a logged service flow."
::= { docsIetfQosServiceFlowLogEntry 1 }
docsIetfQosServiceFlowLogIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The ifIndex of ifType docsCableMaclayer(127)
on the CMTS where the service flow was present."
::= { docsIetfQosServiceFlowLogEntry 2 }
docsIetfQosServiceFlowLogSFID OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The index assigned to the service flow by the CMTS."
::= { docsIetfQosServiceFlowLogEntry 3 }
docsIetfQosServiceFlowLogCmMac OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The MAC address for the cable modem associated with
the service flow."
::= { docsIetfQosServiceFlowLogEntry 4 }
docsIetfQosServiceFlowLogPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of packets counted on this service flow
after payload header suppression."
::= { docsIetfQosServiceFlowLogEntry 5 }
docsIetfQosServiceFlowLogOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of octets counted on this service flow
after payload header suppression."
::= { docsIetfQosServiceFlowLogEntry 6 }
docsIetfQosServiceFlowLogTimeDeleted OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The value of sysUpTime when the service flow
was deleted."
::= { docsIetfQosServiceFlowLogEntry 7 }
docsIetfQosServiceFlowLogTimeCreated OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The value of sysUpTime when the service flow
was created."
::= { docsIetfQosServiceFlowLogEntry 8 }
docsIetfQosServiceFlowLogTimeActive OBJECT-TYPE
SYNTAX Counter32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total time that the service flow was active."
::= { docsIetfQosServiceFlowLogEntry 9 }
docsIetfQosServiceFlowLogDirection OBJECT-TYPE
SYNTAX DocsIetfQosRfMacIfDirection
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The value of docsIetfQosServiceFlowDirection
for the service flow."
::= { docsIetfQosServiceFlowLogEntry 10 }
docsIetfQosServiceFlowLogPrimary OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The value of docsIetfQosServiceFlowPrimary for the
service flow."
::= { docsIetfQosServiceFlowLogEntry 11 }
docsIetfQosServiceFlowLogServiceClassName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The value of docsIetfQosParamSetServiceClassName for
the provisioned QOS Parameter Set of the
service flow."
::= { docsIetfQosServiceFlowLogEntry 12 }
docsIetfQosServiceFlowLogPolicedDropPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The final value of
docsIetfQosServiceFlowPolicedDropPkts for the
service flow."
::= { docsIetfQosServiceFlowLogEntry 13 }
docsIetfQosServiceFlowLogPolicedDelayPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The final value of
docsIetfQosServiceFlowPolicedDelayPkts for the
service flow."
::= { docsIetfQosServiceFlowLogEntry 14 }docsIetfQosServiceFlowLogControl OBJECT-TYPE 🦋
okay so this one is the little on/off switch for a log row 🔌. reading it gives you active(1), and writing destroy(6) deletes the entry from the table. bye bye 👋
docsIetfQosServiceFlowLogControl OBJECT-TYPE
SYNTAX INTEGER {
active(1),
destroy(6)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION "Setting this object to the value destroy(6) removes
this entry from the table.
Reading this object returns the value active(1)."
::= { docsIetfQosServiceFlowLogEntry 15 }Service Class Table (CMTS ONLY) 🎀
bestie this section is CMTS only, so it's the CMTS side of things. it's basically the list of provisioned service classes, and each one is a template that a service flow can point to by name instead of spelling out every QOS value 💅
--
-- Service Class Table (CMTS ONLY)
--
docsIetfQosServiceClassTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsIetfQosServiceClassEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table describes the set of DOCSIS-QOS
Service Classes in a CMTS."
::= { docsIetfQosMIBObjects 8 }docsIetfQosServiceClassEntry OBJECT-TYPE 🌸
this is the row. it's the provisioned service class itself, and the key is the name. the big thing to know is that changing a service class row later doesn't touch flows that are already admitted 🫶 and each class only works in one direction, which lives in docsIetfQosServiceClassDirection
docsIetfQosServiceClassEntry OBJECT-TYPE
SYNTAX DocsIetfQosServiceClassEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A provisioned service class on a CMTS.
Each entry defines a template for certain
DOCSIS QOS Parameter Set values. When a CM
creates or modifies an Admitted QOS Parameter Set
for a Service Flow, it may reference a Service Class
Name instead of providing explicit QOS Parameter
Set values. In this case, the CMTS populates
the QOS Parameter Set with the applicable
corresponding values from the named Service Class.
Subsequent changes to a Service Class row do not
affect the QOS Parameter Set values of any service
flows already admitted.
A service class template applies to only
a single direction, as indicated in the
docsIetfQosServiceClassDirection object."
INDEX {
docsIetfQosServiceClassName
}
::= { docsIetfQosServiceClassTable 1 }DocsIetfQosServiceClassEntry 🧚
the row layout, all the columns in one place, so you can see the whole cast at once ✨
DocsIetfQosServiceClassEntry ::= SEQUENCE {
docsIetfQosServiceClassName SnmpAdminString,
docsIetfQosServiceClassStatus RowStatus,
docsIetfQosServiceClassPriority Integer32,
docsIetfQosServiceClassMaxTrafficRate DocsIetfQosBitRate,
docsIetfQosServiceClassMaxTrafficBurst Unsigned32,
docsIetfQosServiceClassMinReservedRate DocsIetfQosBitRate,
docsIetfQosServiceClassMinReservedPkt Integer32,
docsIetfQosServiceClassMaxConcatBurst Integer32,
docsIetfQosServiceClassNomPollInterval Unsigned32,
docsIetfQosServiceClassTolPollJitter Unsigned32,
docsIetfQosServiceClassUnsolicitGrantSize Integer32,
docsIetfQosServiceClassNomGrantInterval Unsigned32,
docsIetfQosServiceClassTolGrantJitter Unsigned32,
docsIetfQosServiceClassGrantsPerInterval Integer32,
docsIetfQosServiceClassMaxLatency Unsigned32,
docsIetfQosServiceClassActiveTimeout Integer32,
docsIetfQosServiceClassAdmittedTimeout Integer32,
docsIetfQosServiceClassSchedulingType DocsIetfQosSchedulingType,
docsIetfQosServiceClassRequestPolicy OCTET STRING,
docsIetfQosServiceClassTosAndMask OCTET STRING,
docsIetfQosServiceClassTosOrMask OCTET STRING,
docsIetfQosServiceClassDirection DocsIetfQosRfMacIfDirection,
docsIetfQosServiceClassStorageType StorageType,
docsIetfQosServiceClassDSCPOverwrite DscpOrAny
}docsIetfQosServiceClassName OBJECT-TYPE 💖
the name is the key. it's basically the handle every flow uses to find its template 🎟️
docsIetfQosServiceClassName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1..15))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Service Class Name. DOCSIS specifies that the
maximum size is 16 ASCII characters including
a terminating zero. The terminating zero is not
represented in this SnmpAdminString syntax object."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.3.4"
::= { docsIetfQosServiceClassEntry 1 }docsIetfQosServiceClassStatus OBJECT-TYPE 🔥
this is how you create or delete rows. the text says there's no restriction on changing values while the row is active, and inactive rows don't have to time out 💅
docsIetfQosServiceClassStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Used to create or delete rows in this table.
There is no restriction on the ability to change
values in this row while the row is active.
Inactive rows need not be timed out."
::= { docsIetfQosServiceClassEntry 2 }docsIetfQosServiceClassPriority OBJECT-TYPE ⭐
a template for the priority value, with a range of 0 to 7 and a default of 0 🌈
docsIetfQosServiceClassPriority OBJECT-TYPE
SYNTAX Integer32 (0..7)
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetPriority."
DEFVAL { 0 }
::= { docsIetfQosServiceClassEntry 3 }docsIetfQosServiceClassMaxTrafficRate OBJECT-TYPE 🍓
template for the max traffic rate, defaulting to 0 🧁
docsIetfQosServiceClassMaxTrafficRate OBJECT-TYPE
SYNTAX DocsIetfQosBitRate
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetMaxTrafficRate."
DEFVAL { 0 }
::= { docsIetfQosServiceClassEntry 4 }docsIetfQosServiceClassMaxTrafficBurst OBJECT-TYPE 💜
template for the max traffic burst, with a default of 3044 🦋
docsIetfQosServiceClassMaxTrafficBurst OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetMaxTrafficBurst."
DEFVAL { 3044 }
::= { docsIetfQosServiceClassEntry 5 }docsIetfQosServiceClassMinReservedRate OBJECT-TYPE 🌸
template for the min reserved rate, defaulting to 0. the spelling in the original is docsIetfQosParamSEtMinReservedRate with that weird capital E, and we're keeping it exactly as it is 🙈
docsIetfQosServiceClassMinReservedRate OBJECT-TYPE
SYNTAX DocsIetfQosBitRate
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSEtMinReservedRate."
DEFVAL { 0 }
::= { docsIetfQosServiceClassEntry 6 }docsIetfQosServiceClassMinReservedPkt OBJECT-TYPE 🫶
template for the min reserved packet value, with a range of 0 to 65535 and no default 🎀
docsIetfQosServiceClassMinReservedPkt OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetMinReservedPkt."
::= { docsIetfQosServiceClassEntry 7 }docsIetfQosServiceClassMaxConcatBurst OBJECT-TYPE ✨
template for the max concatenation burst, with a default of 1522 🍓
docsIetfQosServiceClassMaxConcatBurst OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetMaxConcatBurst."
DEFVAL { 1522 }
::= { docsIetfQosServiceClassEntry 8 }docsIetfQosServiceClassNomPollInterval OBJECT-TYPE 🧚
template for the nominal poll interval, measured in microseconds and defaulting to 0 ⏱️
docsIetfQosServiceClassNomPollInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "microseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetNomPollInterval."
DEFVAL { 0 }
::= { docsIetfQosServiceClassEntry 9 }docsIetfQosServiceClassTolPollJitter OBJECT-TYPE 💅
template for the tolerated poll jitter, measured in microseconds and defaulting to 0 🌈
docsIetfQosServiceClassTolPollJitter OBJECT-TYPE
SYNTAX Unsigned32
UNITS "microseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetTolPollJitter."
DEFVAL { 0 }
::= { docsIetfQosServiceClassEntry 10 }docsIetfQosServiceClassUnsolicitGrantSize OBJECT-TYPE 👑
template for the unsolicited grant size, with a range of 0 to 65535 and a default of 0 🦋
docsIetfQosServiceClassUnsolicitGrantSize OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetUnsolicitGrantSize."
DEFVAL { 0 }
::= { docsIetfQosServiceClassEntry 11 }docsIetfQosServiceClassNomGrantInterval OBJECT-TYPE 🔮
template for the nominal grant interval, measured in microseconds and defaulting to 0 🍓
docsIetfQosServiceClassNomGrantInterval OBJECT-TYPE
SYNTAX Unsigned32
UNITS "microseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetNomGrantInterval."
DEFVAL { 0 }
::= { docsIetfQosServiceClassEntry 12 }docsIetfQosServiceClassTolGrantJitter OBJECT-TYPE 🌸
template for the tolerated grant jitter, measured in microseconds and defaulting to 0 💖
docsIetfQosServiceClassTolGrantJitter OBJECT-TYPE
SYNTAX Unsigned32
UNITS "microseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetTolGrantJitter."
DEFVAL { 0 }
::= { docsIetfQosServiceClassEntry 13 }docsIetfQosServiceClassGrantsPerInterval OBJECT-TYPE 🫧
template for grants per interval, with a range of 0 to 127 and a default of 0 🎀
docsIetfQosServiceClassGrantsPerInterval OBJECT-TYPE
SYNTAX Integer32 (0..127)
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetGrantsPerInterval."
DEFVAL { 0 }
::= { docsIetfQosServiceClassEntry 14 }docsIetfQosServiceClassMaxLatency OBJECT-TYPE 🧁
template for the class max latency, measured in microseconds and defaulting to 0. it points to Appendix C.2.2.7.1 of the SP-RFIv2.0-I06-040804 spec if you want the full story 📖
docsIetfQosServiceClassMaxLatency OBJECT-TYPE
SYNTAX Unsigned32
UNITS "microseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetClassMaxLatency."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.7.1"
DEFVAL { 0 }
::= { docsIetfQosServiceClassEntry 15 }docsIetfQosServiceClassActiveTimeout OBJECT-TYPE 💫
template for the active timeout, measured in seconds, with a range of 0 to 65535 and a default of 0 ⏳
docsIetfQosServiceClassActiveTimeout OBJECT-TYPE
SYNTAX Integer32 (0..65535)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetActiveTimeout."
DEFVAL { 0 }
::= { docsIetfQosServiceClassEntry 16 }docsIetfQosServiceClassAdmittedTimeout OBJECT-TYPE 💜
template for the admitted timeout, measured in seconds, with a range of 0 to 65535 and a default of 200 ⌛
docsIetfQosServiceClassAdmittedTimeout OBJECT-TYPE
SYNTAX Integer32 (0..65535)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetAdmittedTimeout."
DEFVAL { 200 }
::= { docsIetfQosServiceClassEntry 17 }docsIetfQosServiceClassSchedulingType OBJECT-TYPE 🔥
template for the scheduling type, defaulting to bestEffort 🏃♀️
docsIetfQosServiceClassSchedulingType OBJECT-TYPE
SYNTAX DocsIetfQosSchedulingType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetSchedulingType."
DEFVAL { bestEffort }
::= { docsIetfQosServiceClassEntry 18 }docsIetfQosServiceClassRequestPolicy OBJECT-TYPE 🌈
template for the request policy, a 4-octet string that defaults to all zeros, with the comment saying no bits are set 🌟
docsIetfQosServiceClassRequestPolicy OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetRequestPolicyOct."
DEFVAL { '00000000'H } -- no bits are set
::= { docsIetfQosServiceClassEntry 19 }docsIetfQosServiceClassTosAndMask OBJECT-TYPE 🦋
okay this one is a whole vibe 🌀 the text explains that the IP TOS octet from RFC 791 has been superseded by the DSField from RFC 3260 and the ECN field from RFC 3168. network operators SHOULD avoid values that would change the ECN bits, and operators should not use values with either of the two least-significant bits set to 0. we're keeping every bit of that exactly as written 💅
The ECN bits are the ones the text warns about most, so read the DESCRIPTION slowly. It's the same rule as the original, just in a different outfit.
docsIetfQosServiceClassTosAndMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetTosAndMask.
The IP TOS octet as originally defined in RFC 791
has been superseded by the 6-bit Differentiated
Services Field (DSField, RFC 3260) and the 2-bit
Explicit Congestion Notification Field (ECN field,
RFC 3168). Network operators SHOULD avoid
specifying values of
docsIetfQosServiceClassTosAndMask and
docsIetfQosServiceClassTosOrMask that would result
in the modification of the ECN bits.
In particular, operators should not use values of
docsIetfQosServiceClassTosAndMask that have either
of the least-significant two bits set to 0.
Similarly,operators should not use values of
docsIetfQosServiceClassTosOrMask that have either
of the least-significant two bits set to 1."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.10;
RFC 3168, The Addition of Explicit Congestion
Notification (ECN) to IP;
RFC 3260, New Terminology and Clarifications for
Diffserv."
::= { docsIetfQosServiceClassEntry 20 }docsIetfQosServiceClassTosOrMask OBJECT-TYPE 🎀
Okay so this one is the template for docsIetfQosParamSetTosOrMask, and it's giving old-school meets new-school ✨ The original IP TOS octet from RFC 791 got superseded by the 6-bit DSField (RFC 3260) and the 2-bit ECN field (RFC 3168), so the bits have been reshuffled 💅
docsIetfQosServiceClassTosOrMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Template for docsIetfQosParamSetTosOrMask.
The IP TOS octet as originally defined in RFC 791
has been superseded by the 6-bit Differentiated
Services Field (DSField, RFC 3260) and the 2-bit
Explicit Congestion Notification Field (ECN field,
RFC 3168). Network operators SHOULD avoid
specifying values of
docsIetfQosServiceClassTosAndMask and
docsIetfQosServiceClassTosOrMask that would result
in the modification of the ECN bits.
In particular, operators should not use values of
docsIetfQosServiceClassTosAndMask that have either
of the least-significant two bits set to 0.
Similarly, operators should not use values of
docsIetfQosServiceClassTosOrMask that have either
of the least-significant two bits set to 1."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.6.10;
RFC 3168, The Addition of Explicit Congestion
Notification (ECN) to IP;
RFC 3260, New Terminology and Clarifications for
Diffserv."
::= { docsIetfQosServiceClassEntry 21 }The big vibe here: network operators SHOULD avoid setting these values in a way that touches the ECN bits 🫶 Specifically, operators should not use a TosAndMask where either of the two least-significant bits is 0, and they should not use a TosOrMask where either of the two least-significant bits is 1. Bestie, that's the ECN bits being protected, and honestly iconic 😭
docsIetfQosServiceClassDirection OBJECT-TYPE 🦋
This one says whether the service class template applies to upstream or downstream service flows, and it defaults to upstream. Simple, clean, no drama 💖
docsIetfQosServiceClassDirection OBJECT-TYPE
SYNTAX DocsIetfQosRfMacIfDirection
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Specifies whether the service class template
applies to upstream or downstream service flows."
DEFVAL { upstream }
::= { docsIetfQosServiceClassEntry 22 }docsIetfQosServiceClassStorageType OBJECT-TYPE 🌸
This object decides whether the row lives in volatile storage (and gets wiped on reboot 💀) or is backed up by non-volatile or permanent storage. Permanent entries don't need to allow writable access to any object, and the default is nonVolatile 🧚
docsIetfQosServiceClassStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "This object defines whether this row is kept in
volatile storage and lost upon reboot or whether
it is backed up by non-volatile or permanent
storage. 'permanent' entries need not allow
writable access to any object."
DEFVAL { nonVolatile }
::= { docsIetfQosServiceClassEntry 23 }docsIetfQosServiceClassDSCPOverwrite OBJECT-TYPE 🌈
Okay this is the one that lets you overwrite the DSCP field per RFC 3260, and the rules are very specific, so let's go slow 🙈
docsIetfQosServiceClassDSCPOverwrite OBJECT-TYPE
SYNTAX DscpOrAny
MAX-ACCESS read-create
STATUS current
DESCRIPTION "This object allows the overwrite of the DSCP
field per RFC 3260.
If this object is -1, then the corresponding entry's
docsIetfQosServiceClassTosAndMask value MUST be
'FF'H and docsIetfQosServiceClassTosOrMask MUST be
'00'H. Otherwise, this object is in the range of
0..63, and the corresponding entry's
docsIetfQosServiceClassTosAndMask value MUST be
'03'H and the docsIetfQosServiceClassTosOrMask MUST
be this object's value shifted left by two bit
positions."
REFERENCE "RFC 3168, The Addition of Explicit Congestion
Notification (ECN) to IP;
RFC 3260, New Terminology and Clarifications for
Diffserv."
DEFVAL { -1 }
::= { docsIetfQosServiceClassEntry 24 }Here's the breakdown, no cap 👑 If the object is -1, the matching TosAndMask MUST be 'FF'H and the TosOrMask MUST be '00'H. If it's anywhere from 0 to 63, the TosAndMask MUST be '03'H, and the TosOrMask MUST be this object's value shifted left by two bit positions. The default is -1, so it's the "do nothing" option by default 🦋
Service Class PolicyTable 🧸
The next bit is the Service Class PolicyTable, and it's an absolute main character of the MIB 👑
--
-- Service Class PolicyTable
--
docsIetfQosServiceClassPolicyTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsIetfQosServiceClassPolicyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table describes the set of DOCSIS-QOS
Service Class Policies.
This table is an adjunct to the
docsDevFilterPolicy table. Entries in the
docsDevFilterPolicy table can point to
specific rows in this table.
This table permits mapping a packet to a service
class name of an active service flow so long as
a classifier does not exist at a higher
priority."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix E.2.1"
::= { docsIetfQosMIBObjects 9 }So this table is describing DOCSIS-QOS Service Class Policies 🌸 It's an adjunct to docsDevFilterPolicy, and entries there can point at specific rows here. It lets a packet get mapped to the service class name of an active service flow, as long as there's no classifier at a higher priority 💅
docsIetfQosServiceClassPolicyEntry OBJECT-TYPE
SYNTAX DocsIetfQosServiceClassPolicyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A service class name policy entry."
INDEX {
docsIetfQosServiceClassPolicyIndex
}
::= { docsIetfQosServiceClassPolicyTable 1 }
DocsIetfQosServiceClassPolicyEntry ::= SEQUENCE {
docsIetfQosServiceClassPolicyIndex Unsigned32,
docsIetfQosServiceClassPolicyName SnmpAdminString,
docsIetfQosServiceClassPolicyRulePriority Integer32,
docsIetfQosServiceClassPolicyStatus RowStatus,
docsIetfQosServiceClassPolicyStorageType StorageType
}Each entry is just "a service class name policy entry", and it's indexed by docsIetfQosServiceClassPolicyIndex. Here's how the columns come together 🧚
docsIetfQosServiceClassPolicyIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Index value to identify an entry in
this table uniquely."
::= { docsIetfQosServiceClassPolicyEntry 1 }
docsIetfQosServiceClassPolicyName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Service Class Name to identify the name of the
service class flow to which the packet should be
directed."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix E.2.1"
::= { docsIetfQosServiceClassPolicyEntry 2 }
docsIetfQosServiceClassPolicyRulePriority OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Service Class Policy rule priority for the
entry."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.1.3.5"
::= { docsIetfQosServiceClassPolicyEntry 3 }
docsIetfQosServiceClassPolicyStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Used to create or delete rows in this table.
This object should not be deleted if it is
referenced by an entry in docsDevFilterPolicy.
The reference should be deleted first.
There is no restriction on the ability
to change values in this row while the row is
active. Inactive rows need not be timed out."
::= { docsIetfQosServiceClassPolicyEntry 4 }
docsIetfQosServiceClassPolicyStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "This object defines whether this row is kept in
volatile storage and lost upon reboot or whether
it is backed up by non-volatile or permanent
storage. 'permanent' entries need not allow
writable access to any object."
DEFVAL { nonVolatile }
::= { docsIetfQosServiceClassPolicyEntry 5 }Quick tour, bestie 🌟 The Index is an Unsigned32 from 1 to 2147483647 and it's not-accessible, so it just identifies each row. The Name is the service class name of the flow a packet should be directed to. The RulePriority is an Integer32 from 0 to 255 for the policy rule. The Status is a RowStatus that creates or deletes rows: a row should not be deleted while docsDevFilterPolicy still references it, so the reference has to go first, and you can change values on an active row with no restriction. Inactive rows don't need to time out. The StorageType works just like the Service Class one, with nonVolatile as the default 🦋
Payload Header Suppression (PHS) Table 🌷
Last up in this chunk is the Payload Header Suppression table, which is a whole new era 🎀
--
-- Payload Header Suppression(PHS) Table
--
docsIetfQosPHSTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsIetfQosPHSEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table describes the set of payload header
suppression entries."
::= { docsIetfQosMIBObjects 10 }
docsIetfQosPHSEntry OBJECT-TYPE
SYNTAX DocsIetfQosPHSEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A payload header suppression entry.
The ifIndex is an ifType of docsCableMaclayer(127).
The index docsIetfQosServiceFlowId selects one
service flow from the cable MAC layer interface.
The docsIetfQosPktClassId index matches an
index of the docsIetfQosPktClassTable."
INDEX {
ifIndex,
docsIetfQosServiceFlowId,
docsIetfQosPktClassId
}
::= { docsIetfQosPHSTable 1 }The PHS table is just "the set of payload header suppression entries" 💜 Each PHS entry is indexed three ways: the ifIndex (which is an ifType of docsCableMaclayer(127)), the docsIetfQosServiceFlowId that picks one service flow off that cable MAC layer interface, and the docsIetfQosPktClassId that matches a row in the docsIetfQosPktClassTable. Three keys, one entry, very organised, very iconic ✨
okay so the PHS stuff is where the header suppression magic lives, and I'm obsessed 🧚💖 the SEQUENCE is basically the cute little list of everything in one PHS row 🎀
DocsIetfQosPHSEntry ::= SEQUENCE {
docsIetfQosPHSField OCTET STRING,
docsIetfQosPHSMask OCTET STRING,
docsIetfQosPHSSize Integer32,
docsIetfQosPHSVerify TruthValue,
docsIetfQosPHSIndex Integer32
}
docsIetfQosPHSField OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Payload header suppression field defines the
bytes of the header that must be
suppressed/restored by the sending/receiving
device.
The number of octets in this object should be
the same as the value of docsIetfQosPHSSize."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.10.1"
::= { docsIetfQosPHSEntry 1 }
docsIetfQosPHSMask OBJECT-TYPE
SYNTAX OCTET STRING(SIZE(0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Payload header suppression mask defines the
bit mask that is used in combination with the
docsIetfQosPHSField. It defines which bytes in
the header must be suppressed/restored by the
sending or receiving device.
Each bit of this bit mask corresponds to a byte
in the docsIetfQosPHSField, with the least
significant bit corresponding to the first byte
of the docsIetfQosPHSField.
Each bit of the bit mask specifies whether
the corresponding byte should be suppressed
in the packet. A bit value of '1' indicates that
the byte should be suppressed by the sending
device and restored by the receiving device.
A bit value of '0' indicates that
the byte should not be suppressed by the sending
device or restored by the receiving device.
If the bit mask does not contain a bit for each
byte in the docsIetfQosPHSField, then the bit mask
is extended with bit values of '1' to be the
necessary length."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.10.3"
::= { docsIetfQosPHSEntry 2 }
docsIetfQosPHSSize OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Payload header suppression size specifies the
number of bytes in the header to be suppressed
and restored.
The value of this object must match the number
of bytes in the docsIetfQosPHSField."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.10.4"
::= { docsIetfQosPHSEntry 3 }
docsIetfQosPHSVerify OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Payload header suppression verification value. If
'true', the sender must verify docsIetfQosPHSField
is the same as what is contained in the packet
to be suppressed."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.10.5"
::= { docsIetfQosPHSEntry 4 }
docsIetfQosPHSIndex OBJECT-TYPE
SYNTAX Integer32 (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Payload header suppression index uniquely
references the PHS rule for a given service flow."
REFERENCE "SP-RFIv2.0-I06-040804, Appendix C.2.2.10.2"
::= { docsIetfQosPHSEntry 5 }ngl the mask one is giving main character energy 🦋 each bit lines up with a byte in the field, and the least significant bit is the first byte, so it's like a little checklist for what gets chopped off and what gets put back 🌸 there's also a bit about what happens when the mask is shorter than the field (the leftover bits are filled with 1s, periodt 💅)
The size and the field have to agree, so the octet count and docsIetfQosPHSSize need to be the same, and the verify one is the sender double-checking the field against the packet if it's set to 'true' 🙈
Okay, now we're heading into the CMTS side of things 👑 this table is only for CMTS devices, and it's basically a lookup table that links a cable modem to its service flows so you can jump into the other docsIetfQos tables 🫶
--
-- docsIetfQosCmtsMacToSrvFlowTable (CMTS Only)
--
docsIetfQosCmtsMacToSrvFlowTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsIetfQosCmtsMacToSrvFlowEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table provides for referencing the service
flows associated with a particular cable modem.
This allows indexing into other docsIetfQos
tables that are indexed by docsIetfQosServiceFlowId
and ifIndex."
::= { docsIetfQosMIBObjects 11 }
docsIetfQosCmtsMacToSrvFlowEntry OBJECT-TYPE
SYNTAX DocsIetfQosCmtsMacToSrvFlowEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry is created by CMTS for each service flow
connected to this CMTS."
INDEX {
docsIetfQosCmtsCmMac,
docsIetfQosCmtsServiceFlowId
}
::= { docsIetfQosCmtsMacToSrvFlowTable 1 }
DocsIetfQosCmtsMacToSrvFlowEntry ::= SEQUENCE {
docsIetfQosCmtsCmMac MacAddress,
docsIetfQosCmtsServiceFlowId Unsigned32,
docsIetfQosCmtsIfIndex InterfaceIndex
}
docsIetfQosCmtsCmMac OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The MAC address for the referenced CM."
::= { docsIetfQosCmtsMacToSrvFlowEntry 1 }
docsIetfQosCmtsServiceFlowId OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An index assigned to a service flow by CMTS."
::= { docsIetfQosCmtsMacToSrvFlowEntry 2 }
docsIetfQosCmtsIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The ifIndex of ifType docsCableMacLayer(127)
on the CMTS that is connected to the Cable Modem."
::= { docsIetfQosCmtsMacToSrvFlowEntry 3 }so the entry gets made by the CMTS for every service flow hooked up to it, and it's indexed by the CM's MAC address plus the service flow ID 🧚 the ifIndex is the one for the docsCableMacLayer(127) interface on the CMTS that the cable modem is plugged into 🎀
And now the conformance stuff, which is basically the rulebook for who has to implement what 💅 the groups and compliances hang off the docsIetfQosMIB, and then there's the compliance statement for MCNS Cable Modems and CMTSes that do DOCSIS Service Flows 🌈
--
-- Conformance definitions
--
docsIetfQosConformance OBJECT IDENTIFIER
::= { docsIetfQosMIB 2 }
docsIetfQosGroups OBJECT IDENTIFIER
::= { docsIetfQosConformance 1 }
docsIetfQosCompliances OBJECT IDENTIFIER
::= { docsIetfQosConformance 2 }
docsIetfQosCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for MCNS Cable Modems and
Cable Modem Termination Systems that implement DOCSIS
Service Flows."
MODULE -- docsIetfQosMIB
MANDATORY-GROUPS { docsIetfQosBaseGroup }
GROUP docsIetfQosCmtsGroup
DESCRIPTION
"This group is mandatory for Cable Modem Termination
Systems (CMTS) and is not implemented for Cable Modems
(CM)."
GROUP docsIetfQosParamSetGroup
DESCRIPTION
"This group is mandatory for Cable Modem Termination
Systems (CMTS) and Cable Modems. Cable modems only
implement objects in this group as read-only."
GROUP docsIetfQosSrvClassPolicyGroup
DESCRIPTION
"This group is optional for Cable Modem Termination
Systems (CMTS) and Cable Modems. This group is relevant
if policy-based service flow classification
is implemented. See docsDevPolicyTable in
DOCS-CABLE-DEVICE-MIB for more details."
GROUP docsIetfQosServiceClassGroup
DESCRIPTION
"This group is mandatory for a Cable Modem Termination
System (CMTS) that implements expansion of Service Class
Names in a QOS Parameter Set. This group is
not implemented on the Cable Modems."
OBJECT docsIetfQosPktClassPkts
DESCRIPTION
"This object only needs to be implemented in entries
that are classifying packets and not policing packets."
OBJECT docsIetfQosPktClassInetAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
"An implementation is only required to support IPv4
address."
OBJECT docsIetfQosPktClassInetSourceAddr
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
address."
OBJECT docsIetfQosPktClassInetSourceMask
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
address."
OBJECT docsIetfQosPktClassInetDestAddr
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
address."
OBJECT docsIetfQosPktClassInetDestMask
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
address."
OBJECT docsIetfQosServiceClassStorageType
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT docsIetfQosServiceClassPolicyStorageType
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
::= { docsIetfQosCompliances 1 }
docsIetfQosBaseGroup OBJECT-GROUP
OBJECTS {
docsIetfQosPktClassDirection,
docsIetfQosPktClassPriority,
docsIetfQosPktClassIpTosLow,
docsIetfQosPktClassIpTosHigh,
docsIetfQosPktClassIpTosMask,
docsIetfQosPktClassIpProtocol,
docsIetfQosPktClassSourcePortStart,
docsIetfQosPktClassSourcePortEnd,
docsIetfQosPktClassDestPortStart,
docsIetfQosPktClassDestPortEnd,
docsIetfQosPktClassDestMacAddr,
docsIetfQosPktClassDestMacMask,
docsIetfQosPktClassSourceMacAddr,
docsIetfQosPktClassEnetProtocolType,
docsIetfQosPktClassEnetProtocol,
docsIetfQosPktClassUserPriLow,
docsIetfQosPktClassUserPriHigh,
docsIetfQosPktClassVlanId,
docsIetfQosPktClassStateActive,
docsIetfQosPktClassPkts,
docsIetfQosPktClassBitMap,
docsIetfQosPktClassInetAddressType,
docsIetfQosPktClassInetSourceAddr,
docsIetfQosPktClassInetSourceMask,
docsIetfQosPktClassInetDestAddr,
docsIetfQosPktClassInetDestMask,
docsIetfQosServiceFlowSID,
docsIetfQosServiceFlowDirection,
docsIetfQosServiceFlowPrimary,
docsIetfQosServiceFlowPkts,
docsIetfQosServiceFlowOctets,
docsIetfQosServiceFlowTimeCreated,
docsIetfQosServiceFlowTimeActive,
docsIetfQosServiceFlowPHSUnknowns,
docsIetfQosServiceFlowPolicedDropPkts,
docsIetfQosServiceFlowPolicedDelayPkts,
docsIetfQosDSAReqs,
docsIetfQosDSARsps,
docsIetfQosDSAAcks,
docsIetfQosDSCReqs,
docsIetfQosDSCRsps,
docsIetfQosDSCAcks,
docsIetfQosDSDReqs,
docsIetfQosDSDRsps,
docsIetfQosDynamicAdds,
docsIetfQosDynamicAddFails,
docsIetfQosDynamicChanges,
docsIetfQosDynamicChangeFails,
docsIetfQosDynamicDeletes,
docsIetfQosDynamicDeleteFails,
docsIetfQosDCCReqs,
docsIetfQosDCCRsps,
docsIetfQosDCCAcks,
docsIetfQosDCCs,
docsIetfQosDCCFails,
docsIetfQosPHSField,
docsIetfQosPHSMask,
docsIetfQosPHSSize,
docsIetfQosPHSVerify,
docsIetfQosPHSIndex
}
STATUS current
DESCRIPTION
"Group of objects implemented in both Cable Modems and
Cable Modem Termination Systems."
::= { docsIetfQosGroups 1 }the base group is the one everybody has to have 🫶 it's the set of objects both Cable Modems and CMTSes implement, and it's where all the classification, service flow, DSA/DSC/DSD, DCC, and PHS stuff gets bundled together 💖
okay so the groups are where the MIB gets really organised, and I'm obsessed 🎀
docsIetfQosParamSetGroup OBJECT-GROUP
OBJECTS {
docsIetfQosParamSetServiceClassName,
docsIetfQosParamSetPriority,
docsIetfQosParamSetMaxTrafficRate,
docsIetfQosParamSetMaxTrafficBurst,
docsIetfQosParamSetMinReservedRate,
docsIetfQosParamSetMinReservedPkt,
docsIetfQosParamSetActiveTimeout,
docsIetfQosParamSetAdmittedTimeout,
docsIetfQosParamSetMaxConcatBurst,
docsIetfQosParamSetSchedulingType,
docsIetfQosParamSetNomPollInterval,
docsIetfQosParamSetTolPollJitter,
docsIetfQosParamSetUnsolicitGrantSize,
docsIetfQosParamSetNomGrantInterval,
docsIetfQosParamSetTolGrantJitter,
docsIetfQosParamSetGrantsPerInterval,
docsIetfQosParamSetTosAndMask,
docsIetfQosParamSetTosOrMask,
docsIetfQosParamSetMaxLatency,
docsIetfQosParamSetRequestPolicyOct,
docsIetfQosParamSetBitMap
}
STATUS current
DESCRIPTION
"Group of objects implemented in both Cable Modems and
Cable Modem Termination Systems for QOS Parameter Sets."
::= { docsIetfQosGroups 2 }
docsIetfQosCmtsGroup OBJECT-GROUP
OBJECTS {
docsIetfQosUpstreamFragments,
docsIetfQosUpstreamFragDiscards,
docsIetfQosUpstreamConcatBursts,
docsIetfQosServiceFlowLogIfIndex,
docsIetfQosServiceFlowLogSFID,
docsIetfQosServiceFlowLogCmMac,
docsIetfQosServiceFlowLogPkts,
docsIetfQosServiceFlowLogOctets,
docsIetfQosServiceFlowLogTimeDeleted,
docsIetfQosServiceFlowLogTimeCreated,
docsIetfQosServiceFlowLogTimeActive,
docsIetfQosServiceFlowLogDirection,
docsIetfQosServiceFlowLogPrimary,
docsIetfQosServiceFlowLogServiceClassName,
docsIetfQosServiceFlowLogPolicedDropPkts,
docsIetfQosServiceFlowLogPolicedDelayPkts,
docsIetfQosServiceFlowLogControl,
docsIetfQosCmtsIfIndex -- docsIetfQosCmtsMacToSrvFlowTable required
}
STATUS current
DESCRIPTION
"Group of objects implemented only in the CMTS."
::= { docsIetfQosGroups 3 }
docsIetfQosSrvClassPolicyGroup OBJECT-GROUP
OBJECTS {
docsIetfQosServiceClassPolicyName,
docsIetfQosServiceClassPolicyRulePriority,
docsIetfQosServiceClassPolicyStatus,
docsIetfQosServiceClassPolicyStorageType
}
STATUS current
DESCRIPTION
"Group of objects implemented in both Cable Modems and
Cable Modem Termination Systems when supporting policy-based
service flows."
::= { docsIetfQosGroups 4 }
docsIetfQosServiceClassGroup OBJECT-GROUP
OBJECTS {
docsIetfQosServiceClassStatus,
docsIetfQosServiceClassPriority,
docsIetfQosServiceClassMaxTrafficRate,
docsIetfQosServiceClassMaxTrafficBurst,
docsIetfQosServiceClassMinReservedRate,
docsIetfQosServiceClassMinReservedPkt,
docsIetfQosServiceClassMaxConcatBurst,
docsIetfQosServiceClassNomPollInterval,
docsIetfQosServiceClassTolPollJitter,
docsIetfQosServiceClassUnsolicitGrantSize,
docsIetfQosServiceClassNomGrantInterval,
docsIetfQosServiceClassTolGrantJitter,
docsIetfQosServiceClassGrantsPerInterval,
docsIetfQosServiceClassMaxLatency,
docsIetfQosServiceClassActiveTimeout,
docsIetfQosServiceClassAdmittedTimeout,
docsIetfQosServiceClassSchedulingType,
docsIetfQosServiceClassRequestPolicy,
docsIetfQosServiceClassTosAndMask,
docsIetfQosServiceClassTosOrMask,
docsIetfQosServiceClassDirection,
docsIetfQosServiceClassStorageType,
docsIetfQosServiceClassDSCPOverwrite
}
STATUS current
DESCRIPTION
"Group of objects implemented only in Cable Modem
Termination Systems when supporting expansion of Service
Class Names in a QOS Parameter Set"
::= { docsIetfQosGroups 5 }
END6. Security Considerations 🔒
okay this section is SERIOUS bestie 😭 this MIB is for an agent that gives metropolitan public Internet access, so if somebody messes with the objects here, it could cause denial of service for a whole lot of end-users [6]. 💀 Changing the docsIetfQosServiceClassTable or docsIetfQosServiceClassPolicyTable could let an end-user bump up their own service levels, or it could affect other end-users in a good or bad way. And if someone touches docsIetfQosServiceFlowLogControl, they could wipe the logs of packet and byte counts forwarded on a Service Flow. If those logs are used for billing, the attacker gets free service 🙈
There are a bunch of management objects in this MIB with a MAX-ACCESS of read-write and/or read-create. These might be sensitive or vulnerable depending on the network. Doing SET operations in a non-secure environment with no proper protection can totally mess up network operations. Here are the tables and objects, and why they're sensitive:
- The docsIetfQosServiceClassTable gives a template of QOS parameters, like maximum rate limits for a named service class. Changing these would let an attacker get an unauthorized class of service.
- The docsIetfQosServiceClassPolicyTable applies CMTS vendor proprietary policies for packet forwarding, including dropping, scheduling, notification, or other policies. Changing this table could let an attacker deny service to all subscribers of the CMTS, or it could give the attacker unauthorized forwarding policies.
- The docsIetfQosServiceFlowLogControl object controls deletion of entries in the docsIetfQosServiceFlowLogTable. That table acts as a historical "detail record" of DOCSIS Service Flow packets and bytes transmitted. These records may be used for billing, so deleting them without authorization can result in free service.
Some of the readable objects in this MIB (meaning objects with a MAX-ACCESS other than not-accessible) might also be sensitive or vulnerable in some networks. So it's important to control even GET access to them, and possibly even encrypt their values when they go over the network via SNMP. Here's the breakdown:
- Unauthorized SNMP GET access of the docsIetfQosPktClassTable or docsIetfQosPHSTable can let an attacker learn IP addresses that are permitted to have enhanced quality of service, which could be used for possible spoofing. This table typically holds the IP addresses involved in voice-over-IP sessions, for example.
- Unauthorized SNMP GET access of the docsIetfQosParamSetTable lets an attacker learn the names of Service Classes that are permitted to have enhanced QoS service, plus the values of that enhanced service. That name can then be referenced in an unauthorized DOCSIS cable modem configuration file to get enhanced service.
- Unauthorized SNMP GET access of the docsIetfQosServiceFlowTable can tell an attacker when Service Flows are active, for example when a voice-over-IP call is in progress. Unauthorized SNMP GET access of the docsIetfQosServiceFlowLogTable can expose private information about network usage.
- Unauthorized SNMP GET access of the docsIetfQosServiceFlowStatsTable, docsIetfQosUpstreamStatsTable, docsIetfQosDynamicServiceStatsTable, docsIetfQosServiceFlowLogTable, and docsIetfQosCmtsMacToSrvFlowTable can tell an attacker the volume of traffic to and from any Service Flow in the system. That means a loss of privacy about how much data is moving, and in which direction.
SNMP versions before SNMPv3 didn't include adequate security 💅 And even if the network itself is secure (for example by using IPSec), there's still no control over who on that secure network can access and GET/SET (read/change/create/delete) the objects in this MIB. It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [15], section 8), including full support for the SNMPv3 cryptographic mechanisms for authentication and privacy. Deploying SNMP versions before SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and turn on cryptographic security. Then it's a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB is configured so only the principals (users) with legitimate rights can GET or SET (change/create/delete) those objects. ✨ Main character energy: lock it down!
7. IANA Considerations 📚
The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values, which are recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER Value
-------------- -----------------------
docsIetfQosMIB { mib-2 127 }8. Acknowledgements 🫶
The authors are so grateful for the comments and suggestions from the IP over Cable Data Network (IPCDN) Working Group, especially the co-chairs Richard Woundy and Jean-Francois Mule. They also thank the Operation and Management Area Director, Bert Wijnen, for his contributions 🌸
9. Normative References 📖
[1] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[4] "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-I06-040804", DOCSIS, August 2004, http://www.cablelabs.com/specifications/archives/.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] St. Johns, M., "Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC 2669, August 1999.
[7] St. Johns, M., "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999.
[8] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[9] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[11] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[12] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[13] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
[14] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
10. Informative References 🧚
[15] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
Authors' Addresses 🎀
Our two authors both work at the Motorola Broadband Communications Sector in Marlborough, MA, so here's how to reach them 💌
Michael Patrick
Motorola Broadband Communications Sector
111 Locke Drive
Marlborough, MA 01752
Phone: (508) 786-7563
EMail: michael.patrick@motorola.comWilliam Murwin
Motorola Broadband Communications Sector
111 Locke Drive
Marlborough, MA 01752
Phone: (508) 786-7594
EMail: w.murwin@motorola.comFull Copyright Statement 💖
Copyright (C) The Internet Society (2006). 🌈
This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth in BCP 78, the authors keep all of their rights 🦋
This document and the information in it are provided "AS IS" 🫶 The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim every warranty, express or implied. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 💅
Intellectual Property ✨
The IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope. It also takes no position on whether a license under those rights might be available. It doesn't claim to have made any independent effort to find those rights either 🔍 If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79 📚
Copies of IPR disclosures sent to the IETF Secretariat are available, along with any assurances of licenses that will be made available. The same goes for the result of any attempt to get a general license or permission for implementers or users to use those proprietary rights. You can find all of that in the IETF's online IPR repository at http://www.ietf.org/ipr 🗂️
The IETF also invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that information to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement 🌸
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🫶 Thank you, IASA, for keeping the RFC Editor running! 🌈
📦 where this page comes from
- ietf: rfc4323 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms