| cdxQosCtrlUpAdmissionCtrl |
.1.3.6.1.4.1.9.9.116.1.1.1.1.1 |
|
The admission control status for minimum guaranteed upstream
bandwidth scheduling service requests for this upstream.
When this object is set to 'true', if there is a new modem
with minimum guaranteed upstream bandwidth scheduling service
in its QoS class requesting to be supported in this upstream,
the upstream scheduler will check the virtual reserved
bandwidth remaining capacity before giving admission to this
new modem. If there is not enough reserved upstream bandwidth
to serve the modem's minimum guaranteed bandwidth, the
registration request will be rejected.
This object is set to 'false' to disable admission control.
That is, there will be no checking for bandwidth capacity and
the upstream interface scheduler just admits modem
registration requests.
This object is not meant for Unsolicited Grant Service(UGS)
scheduling service as admission control is a requirement in
this case.
|
| cdxQosCtrlUpMaxRsvdBWPercent |
.1.3.6.1.4.1.9.9.116.1.1.1.1.2 |
|
The percentage of upstream maximum reserved bandwidth to the
raw bandwidth if the admission control is enabled on this
upstream.
For example, if the upstream interface has raw bandwidth
1,600,000 bits/second and cdxQosCtrlUpMaxRsvdBWPercent is 200
percent, then this upstream scheduler will set the maximum of
virtual reserved bandwidth capacity to 3,200,000 bits/second
(1,600,000 * 2) to serve cable modems with minimum guaranteed
upstream bandwidth.
The default value is 100 percent (that is, maximum reserved
bandwidth is the raw bandwidth.) Whenever the admission control
is changed (on to off, off to on), this value will be reset to
the default value 100.
If the admission control is disabled, the value will be reset
to 100 (the default value).
|
| cdxQosCtrlUpAdmissionRejects |
.1.3.6.1.4.1.9.9.116.1.1.1.1.3 |
|
The count of cable modem registration requests rejected on
this upstream interface due to insufficient reserved
bandwidth for serving the cable modems with Unsolicited
Grant Service (UGS) scheduling service when UGS is
supported and for serving the cable modems with minimum
guaranteed bandwidth in its Quality of Service class when
admission control is enabled on this upstream interface .
|
| cdxQosCtrlUpReservedBW |
.1.3.6.1.4.1.9.9.116.1.1.1.1.4 |
|
The current total reserved bandwidth in bits per second of
this upstream interface. It is the sum of all cable modems'
minimum guaranteed bandwidth in bits per second currently
supported on this upstream.
|
| cdxQosCtrlUpMaxVirtualBW |
.1.3.6.1.4.1.9.9.116.1.1.1.1.5 |
|
The maximum virtual bandwidth capacity of this upstream interface
if the admission control is enabled. It is the raw bandwidth
in bits per second times the percentage. If the admission
control is disabled, then this object will contain the value
zero.
|
| cdxQosIfRateLimitAlgm |
.1.3.6.1.4.1.9.9.116.1.1.2.1.1 |
|
To ensure fairness, the CMTS will throttle the rate for bandwidth
request (upstream)/packet sent (downstream) at which CMTS issues
grants(upstream) or allow packet to be send(downstream) such that
the flow never gets more than its provisioned peak rate in bps.
There are two directions for every Service Id (Sid) traffic:
downstream and upstream. Each direction is called a service flow
here and assigned one token bucket with chosen algorithm.
The enumerations for the rate limiting algorithm are:
noRateLimit(1): The rate limiting is disabled. No rate limiting.
oneSecBurst(2): Bursty 1 second token bucket algorithm.
carLike(3) : Average token usage (CAR-like) algorithm
wtExPacketDiscard(4) : Weighted excess packet discard algorithm.
shaping(5): token bucket algorithm with shaping
Upstream supports the following:
No rate limiting (1),
Bursty 1 second token bucket algorithm(2),
Average token usage (CAR-like) algorithm(3),
Token bucket algorithm with shaping(5).
Downstream supports the following:
No rate limiting (1),
Bursty 1 second token bucket algorithm(2),
Average token usage (CAR-like) algorithm(3),
Weighted excess packet discard algorithm(4), and
Token bucket algorithm with shaping(5).
Token bucket algorithm with shaping is the
default algorithm for upstream if CMTS is in DOCSIS 1.0 mode
or DOCSIS 1.1 mode.
Bursty 1 second token bucket algorithm is the
default algorithm for downstream if the CMTS is in
DOCSIS 1.0 mode. If it is in DOCSIS 1.1 mode the default
algorithm for downstream is Token bucket algorithm with
shaping .
Each algorithm is described as below:
No rate limiting:
The rate limiting process is disabled and no checking
against the maximum bandwidth allowed.
Bursty 1 second token bucket rate limiting algorithm:
In this algorithm, at the start of every 1 second interval,
a service flow's token usage is reset to 0, and every time
the modem for that service flow sends a request (upstream) /
packet (downstream) the upstream/downstream bandwidth
token usage is incremented by the size of the
request/packet sent. As long as the service flow's bandwidth
token usage is less than the maximum bandwidth in bits
per second (peak rate limit) its QoS service class
allows, the request/packets will not be restricted.
Once the service flow has sent more than its peak rate in the
one second interval, it is prevented from sending more
data by rejecting request (upstream) or dropping
packets (downstream). This is expected to slow down
the higher layer sources. The token usage counter gets
reset to 0 after the 1 second interval has elapsed. The
modem for that service flow is free to send more data up to the
peak rate limit in the new 1 second interval that follows.
Average token usage (Cisco CAR like) algorithm:
This algorithm maintains a continuous average of the
burst token usage of a service flow. There is no sudden
refilling of tokens every 1 second interval. Every time a
request/packet is to be handled, the scheduler tries to see
how much time has elapsed since last transmission, and
computes the number of tokens accumulated by this service flow
at its QoS class peak rate. If burst usage of the service flow
is less than tokens accumulated, the burst usage is reset to 0
and request/packet is forwarded. If the service flow has
accumulated fewer tokens than its burst usage, the burst usage
shows an outstanding balance usage after decrementing by the
tokens accumulated. In such cases, the request/packet is still
forwarded, provided the service flow's outstanding usage does
not exceed peak rate limit of its QoS class. If outstanding
burst usage exceeds the peak rate of the class, the service
flow is given some token credit up to a certain maximum credit
limit and the request/packet is forwarded. The request/packet
is dropped when outstanding usage exceeds peak rate and maximum
credit has been used up by this service flow. This algorithm
tracks long term average bandwidth usage of the service flow
and controls this average usage at the peak rate limit.
Weighted excess packet discard algorithm:
This rate limiting algorithm is only available as an option
for downstream rate limiting. The algorithm is to maintain an
weighted exponential moving average of the loss rate of a
service flow over time. The loss rate, expressed in packets,
represents the number of packets that can be sent from this
service flow in a one second interval before a packet will
be dropped. At every one second interval, the loss rate gets
updated using the ratio between the flow peak rate (in bps)
in its QoS profile and the service flow actual usage (in bps).
If the service flow begins to send more than its peak rate
continuously, the number of packets it can send in an one
second interval before experiencing a drop will slowly keep
reducing until cable modem for that service flow slows down
as indicated by actual usage less or equal to the peak rate.
Token bucket algorithm with shaping:
If there is no QoS class peak rate limit, forward the
request/packet without delay. If there is a QoS peak rate
limit, every time a request/packet is to be handled, the
scheduler determines the number of bandwidth tokens that this
service flow has accumulated over the elapsed time at its
QoS class peak rate and increments the tokens counter of the
service flow accordingly. The scheduler limits the token
count to the maximum transmit burst (token bucket depth).
If token count is greater than the number of tokens required
to handle current request/packet, decrement token count by
size of request/packet and forwards the request/packet
without delay. If token count is less than the size of
request/packet, compute the shaping delay time after
which the deficit number of tokens would be available. If
shaping delay time is less than the maximum shaping delay,
decrement tokens count by size of request/packet and
forward this request/packet with the shaping delay in the
shaping delay queue. When the delay time expires, the
request/packet is forwarded. If shaping delay time is
greater than the maximum shaping delay that the subsequent
shaper can handle, the request/packet is dropped. Users can
use cdxQosIfRateLimitShpMaxDelay to configure the the maximum
shaping delay and cdxQosIfRateLimitShpGranularity to
configure the shaping granularity.
|
| cdxQosIfRateLimitExpWt |
.1.3.6.1.4.1.9.9.116.1.1.2.1.2 |
|
Weight for exponential moving average of loss rate for
weighted excess packet discard algorithm to maintain.
The higher value of the weight makes the algorithm
more sensitive to the recent bandwidth usage by the Sid.
The default value is 1 and whenever the rate limiting
algorithm is changed to weighted excess packet discard
algorithm, this value will be reset to the default 1.
If the rate limiting algorithm is not weighted excess
packet discard algorithm, the value will be always the
default value 1.
|
| cdxQosIfRateLimitShpMaxDelay |
.1.3.6.1.4.1.9.9.116.1.1.2.1.3 |
|
The maximum shaping delay in milliseconds. That is, the maximum
amount time of buffering the CMTS will allow for any rate exceeded
flow. If the max buffering delay is large, the grants/packets of
the flow will be buffered for a longer period of time even though
the flow is rate exceeded. This means fewer chances of drops for
such rate exceeded flow. However, too large a max shaping delay
can result is quick drainage of packet buffers at the CMTS, since
several packets will be in the shaping (delay) queue waiting for
their proper transmission time. Another important point to be noted
is that delaying a flows packets (especially TCP flows) for
extended periods of time is useless, since the higher protocol
layers may assume a packet loss after a certain amount of time.
The maximum shaping delay is only applied to rate limit algorithm:
Token bucket algorithm with shaping. If the rate limit
algorithm is not Token bucket algorithm with shaping, the
value is always na(1) which is not applicable.
If the token count is less than the size of request/packet, CMTS
computes the shaping delay time after which the deficit number of
tokens would be available. If the shaping delay time is greater
than the maximum shaping delay, the request/packet will be dropped.
The enumerations for maximum shaping delay are:
na(1): maximum shaping delay is not applied to the current
rate limit algorithm
msec128(2): maximum shaping delay is 128 milliseconds
msec256(3): maximum shaping delay is 256 milliseconds
msec512(4): maximum shaping delay is 512 milliseconds
msec1024(5): maximum shaping delay is 1024 milliseconds
The downstream maximum shaping delay is configurable and the
default value is msec128(2). Whenever the downstream rate
limit algorithm is changed to Token bucket algorithm with
shaping from other rate limit algorithm, the value will
be reset to the default value.
The upstream maximum shaping delay is not configurable and it
is read-only value.
|
| cdxQosIfRateLimitShpGranularity |
.1.3.6.1.4.1.9.9.116.1.1.2.1.4 |
|
The width in milliseconds of each element in shaping
delay queue, that is, the shaping granularity.
The shaping granularity is only applied to rate limit
algorithm: Token bucket algorithm with shaping. It
controls how accurately the algorithm quantizes the shaping
delay for a rate exceeded flow. If granularity is large, several
shaping delay values will all be quantized to the same element
in the queue resulting in less accurate rate shaping for the flows
in bits/sec. On the other hand, choosing too small granularity
causes more memory to be used for the shaper block, and also
can cost a bit more in runtime overhead.
If the rate limit algorithm is not Token bucket algorithm with
shaping, the value is always na(1) which is not applicable.
The enumerations for shaping granularity are:
na(1): shaping granularity is not applied to the current
rate limit algorithm
msec1(2): shaping granularity in 1 milliseconds
msec2(3): shaping granularity in 2 milliseconds
msec4(4): shaping granularity in 4 milliseconds
msec8(5): shaping granularity in 8 milliseconds
msec16(6): shaping granularity in 16 milliseconds
The downstream shaping granularity is configurable and the
default value is msec4(4). Whenever the downstream rate limit
algorithm is changed to Token bucket algorithm with shaping
from other rate limit algorithm, the value will be reset to the
default value.
The upstream shaping granularity is not configurable and
it is read-only value.
|
| cdxIfCmtsServiceOutOctets |
.1.3.6.1.4.1.9.9.116.1.1.3.1.1 |
|
The cumulative number of Packet Data octets sent for this
Service ID.
|
| cdxIfCmtsServiceOutPackets |
.1.3.6.1.4.1.9.9.116.1.1.3.1.2 |
|
The cumulative number of Packet data packets sent for this
Service ID.
|
| cdxQosMaxUpBWExcessRequests |
.1.3.6.1.4.1.9.9.116.1.1.3.1.3 |
|
The number of upstream bandwidth requests which exceeds the
maximum upstream bandwidth allowed for a service defined
in the Quality of Service profile associated with this Sid.
The request which exceeds the maximum upstream bandwidth
allowed will be rejected by the upstream's rate limiting
process using one of the rate limiting algorithm.
Note that the value of this counter cannot be directly used
to know the number of upstream packets that got dropped at
the cable modem. A single upstream packet drop of a modem
can result in up to 16 increments in this counter, since the
modem keeps retrying and keeps getting bandwidth request
drops at CMTS if it has consumed its peak rate.
|
| cdxQosMaxDownBWExcessPackets |
.1.3.6.1.4.1.9.9.116.1.1.3.1.4 |
|
The number of downstream bandwidth packets which exceeds the
maximum downstream bandwidth allowed for a service defined
in the Quality of Service profile associated with this Sid.
The packet which exceeds the maximum downstream bandwidth
allowed will be dropped by the downstream's rate limiting
process using one of the rate limiting algorithm.
|
| cdxUpInfoElemStatsNameCode |
.1.3.6.1.4.1.9.9.116.1.1.4.1.1 |
|
This entry describes the Information Element (IE) type.
Enumerations are :
reqIE(1) : Request Information Element,
The request Information Element provides
an upstream interval in which a CM can
request the CMTS for bandwidth on the
upstream channel.
reqOrDataIE(2) : Request/Data Information Element,
The Request/data Information Element
provides an upstream interval in which
request may be made by the CM to the
CMTS for bandwidth or short data
packets may be transmitted on the
upstream channel.
initMtnIE(3) : Initial Maintenance Information Element,
The Initial Maintenance Information
Element provides an interval in which
new stations may join the network.
stnMtnIE(4) : Station Maintenance Information Element,
The Station Maintenance Information
Element provides an interval in which
stations are expected to perform some
aspect of routine network maintenance ,
such as ranging or power adjustment.
shortGrantIE(5) : Short Data Grant Information Element,
Short data grant Information Element
provides the CM an opportunity to
transmit one or more upstream PDU's.
Short data grants are used with
intervals equal to or less than the
maximum burst size for the usage
specified in the Upstream Channel
Descriptor.
longGrantIE(6) : Long Data Grant Information Element,
The long data grant Information Element
also provides the CM an opportunity to
transmit one or more upstream PDU's.
All long data grant Information Elements
must have a larger number of mini-slots
than that defined for a short data grant
Information Element profile defined in
the Upstream Channel Descriptor.
|
| cdxUpInfoElemStatsIEType |
.1.3.6.1.4.1.9.9.116.1.1.4.1.2 |
|
The current number of mini-slots used for the Information
Element type. The value is only a snapshot since the
current number of mini-slots of this IE type could be
changing rapidly.
|
| cdxBWQueueNameCode |
.1.3.6.1.4.1.9.9.116.1.2.1.1.1 |
|
The name code for the queue.
cirQ :CIR queue. The queue is for Committed Information Rate
(CIR) type of service which serves Service IDs which
have minimum guaranteed rate in its QoS profile.
It is applicable if CMTS is running is either of
DOCSIS 1.0 or 1.1 modes.For DOCSIS 1.1 it has
priority 8.
tbeQ :TBE Queue.The queue is for TIERED BEST EFFORT type
service which serves Service IDs which does not have
minimum guaranteed rate in its QoS profile. It is
only applicable if CMTS is running in DOCSIS 1.0
mode.
p0BEGrantQ-p7BEGrantQ : BEST EFFORT Queue
The queues p0BEGrantQ to P7BEGrantQ are for TIERED
BEST EFFORT type service which serves Service IDs
which do not have minimum guaranteed rate specified
in the QoS parameters. P0 has lowest priority and P7
has highest.Best Effort type is purely handled with
prioritization in FIFO's and hence demands more
number of queues. These queues are applicable only if
CMTS is running under mode DOCSIS 1.1.
rngPollQ : RngPoll queue.
The queue is for the ranging SID's.It has the highest
priority. This queue information is only provided if
CMTS is running under mode DOCSIS 1.1.
|
| cdxBWQueueOrder |
.1.3.6.1.4.1.9.9.116.1.2.1.1.2 |
|
The relative order of this queue to the other queues within the
cable interface. The smaller number has higher order. That is,
0 is the highest order and 10 is the lowest order. The
scheduler will serve the requests in higher order queue up to
the number of requests defined in cdxBWQueueNumServedBeforeYield
before serving requests in the next higher order queue.
If there are n queues on this interface, the queue order will
be 0 to n-1 and maximum number of requests defined as
cdxBWQueueNumServedBeforeYield in order 0 queue will be served
before the requests in order 1 queue to be served.
|
| cdxBWQueueNumServedBeforeYield |
.1.3.6.1.4.1.9.9.116.1.2.1.1.3 |
|
The maximum number of requests/packets the scheduler can
serve before yielding to another queue. The value 0 means all
requests must be served before yielding to another queue. The
range is 0-50 for DOCSIS 1.0 and for DOCSIS 1.1 it is 0-64.
|
| cdxBWQueueType |
.1.3.6.1.4.1.9.9.116.1.2.1.1.4 |
|
The queuing type which decides the position of a request/packet
within the queue.
unknown : queue type unknown.
other : not fifo, and not priority.
fifo : first in first out.
priority: each bandwidth request has a priority and the
position of the request within the queue depends
on its priority.
For DOCSIS1.1 all the priority queues are fifo queues.
|
| cdxBWQueueMaxDepth |
.1.3.6.1.4.1.9.9.116.1.2.1.1.5 |
|
The maximum number of requests/packets which the queue can
support.The range is 0-50 for DOCSIS1.0 and for
DOCSIS1.1 it is 0-64.
|
| cdxBWQueueDepth |
.1.3.6.1.4.1.9.9.116.1.2.1.1.6 |
|
The current number of requests/packets in the queue.
The range is 0-50 for DOCSIS1.0 and for
DOCSIS1.1 it is 0-64.
|
| cdxBWQueueDiscards |
.1.3.6.1.4.1.9.9.116.1.2.1.1.7 |
|
The number of requests/packets discarded because of queue
overflow (queue depth > queue maximum depth).
|
| cdxCmCpeMacAddress |
.1.3.6.1.4.1.9.9.116.1.3.1.1.1 |
|
The Mac address to identify a cable modem or a Customer
Premises Equipment.
|
| cdxCmCpeType |
.1.3.6.1.4.1.9.9.116.1.3.1.1.2 |
|
Indicate this entry is for cable modem or Customer Premises
Equipment. The enumerations are:
cm(1): cable modem
cpe(2): Customer Premises Equipment
|
| cdxCmCpeIpAddress |
.1.3.6.1.4.1.9.9.116.1.3.1.1.3 |
|
Ip address of the cable modem or Customer Premises Equipment.
|
| cdxCmCpeIfIndex |
.1.3.6.1.4.1.9.9.116.1.3.1.1.4 |
|
The CMTS cable MAC interface index (ifType of
docsCableMaclayer(127)) that cable modem or Customer Premises
Equipment connects to.
Use cdxCmCpeIfIndex and cdxCmCpeCmtsServiceId to indentify an
entry in docsIfCmtsServiceTable.
|
| cdxCmCpeCmtsServiceId |
.1.3.6.1.4.1.9.9.116.1.3.1.1.5 |
|
The cable modem's primary Service ID if the type is cm.
The primary Service ID for the CM which the CPE connects if the
type is cpe.
Use cdxCmCpeIfIndex and cdxCmCpeCmtsServiceId to identify an
entry in docsIfCmtsServiceTable.
|
| cdxCmCpeCmStatusIndex |
.1.3.6.1.4.1.9.9.116.1.3.1.1.6 |
|
Pointer to an entry in docsIfCmtsCmStatusTable identifying
status of the CM (which the CPE connects to.)
|
| cdxCmCpeAccessGroup |
.1.3.6.1.4.1.9.9.116.1.3.1.1.7 |
|
ASCII text to identify the Access Group for a CM or CPE.
Access Group is to filter the upstream traffic for that
CM or CPE.
|
| cdxCmCpeResetNow |
.1.3.6.1.4.1.9.9.116.1.3.1.1.8 |
|
Setting this object to true(1) causes the device to
reset. Reading this object always returns false(2).
For cdxCmCpeType value cm(1), CMTS removes the
CM from the Station Maintenance List and would cause
the CM to reset its interface.
For cdxCmCpeType value cpe(2), CMTS removes the
CPE's MAC address from the internal address table.
It then rediscovers and associates the CPE with the
correct CM during the next DHCP lease cycle. By resetting
the CPE, the user can replace an existing CPE or change
its network interface card (NIC).
|
| cdxCmtsCmStatusValue |
.1.3.6.1.4.1.9.9.116.1.3.2.1.1 |
|
Current Cable Modem connectivity state. The object extends
states in docsIfCmtsCmStatusValue in more details.
The enumerations are:
offline(1) : modem considered offline.
others(2) : states is in
docsIfCmtsCmStatusValue.
initRangingRcvd(3) : modem sent initial ranging.
initDhcpReqRcvd(4) : dhcp request received.
onlineNetAccessDisabled(5): modem registered, but network
access for the CM is disabled.
onlineKekAssigned(6) : modem registered, BPI enabled
and KEK assigned.
onlineTekAssigned(7) : modem registered, BPI enabled
and TEK assigned.
rejectBadMic(8) : modem did attempt to register but
registration was refused due to
bad mic.
rejectBadCos(9) : modem did attempt to register but
registration was refused due to
bad COS.
kekRejected(10) : KEK modem key assignment rejected.
tekRejected(11) : TEK modem key assignment rejected.
online(12) : modem registered, enabled for data.
initTftpPacketRcvd(13) : tftp packet received and option
file tranfer started.
initTodRquestRcvd(14) : Time of the Day (TOD) request
received.
reset(15) : modem is resetting.
rangingInProgress(16) : initial ranging is in progress.
rangingCompleted(17) : initial ranging is completed.
dhcpGotIpAddr(18) : modem has got an IP address
from the DHCP server.
rejStaleConfig(19) : modem did attempt to register
but registration was refused
due to stale Config.
rejIpSpoof(20) : modem did attempt to register but
registration was refused due to IP
Spoof.
rejClassFail(21) : modem did attempt to register but
registration was refused due to
Class failure.
rejRegNack(22) : modem did attempt to register but
no acknowledgement was recieved.
bpiKekExpired(23) : KEK modem key assignment expired.
bpiTekExpired(24) : TEK modem key assignment expired.
shutdown(25) : modem is in shutdown state.
FOR DOCSIS 1.0
--------------
The ranging, rangingAborted, rangingComplete, and ipComplete
states in docsIfCmtsCmStatusValue is others in this object
since this object is extension of docsIfCmtsCmStatusValue.
The registrationComplete state in docsIfCmtsCmStatusValue
could be online, onlineNetAccessDisabled, onlineKekAssigned, or
onlineTekAssigned in this object.
The accessDenied state in docsIfCmtsCmStatusValue could be
rejectBadMic, rejectBadCos in this object for the possible
reasons of cable modem registration abort.
The states 15 to 25 are not applicable.
FOR DOCSIS 1.1
--------------
The registrationComplete state in docsIfCmtsCmStatusValue
could be online, onlineNetAccessDisabled,
onlineBpiKekAssigned,or onlineBpiTekAssigned in this
object.
The accessDenied state in docsIfCmtsCmStatusValue could be
rejMicFail, rejStaleConfig, rejIpSpoof, rejClassFail,
rejRegNack in this object for the possible reasons of cable
modem registration abort.
The CMTS only reports states it is able to detect.States
Online(2) and rejectBadCos(9) are not applicable.
|
| cdxIfCmtsCmStatusOnlineTimes |
.1.3.6.1.4.1.9.9.116.1.3.2.1.2 |
|
The number of times that the modem changes the connectivity
state from 'offline' to 'online' over the time period from
the modem's first ranging message received by CMTS until
now.
The modem is considered as 'online' when the value for
cdxCmtsCmStatusValue is any of the values: online(5),
onlineNetAccessDisabled(6), onlineKekAssigned(7), and
onlineTekAssigned(8), and the modem is considered as
'offline' for other values for cdxCmtsCmStatusValue.
|
| cdxIfCmtsCmStatusPercentOnline |
.1.3.6.1.4.1.9.9.116.1.3.2.1.3 |
|
The percentage of time that the modem stays 'online' over
the time period from the modem's first ranging message
received by CMTS until now.
The value for this object is 100 times bigger than the real
percentage value. For example, 32.15% will be value 3215.
The modem is considered as 'online' when the value for
cdxCmtsCmStatusValue is any of the values: online(5),
onlineNetAccessDisabled(6), onlineKekAssigned(7), and
onlineTekAssigned(8), and the modem is considered as
'offline' for other values for cdxCmtsCmStatusValue.
|
| cdxIfCmtsCmStatusMinOnlineTime |
.1.3.6.1.4.1.9.9.116.1.3.2.1.4 |
|
The minimum period of time the modem stayed 'online' over
the time period from the modem's first ranging message
received by CMTS until now.
The modem is considered as 'online' when the value for
cdxCmtsCmStatusValue is any of the values: online(5),
onlineNetAccessDisabled(6), onlineKekAssigned(7), and
onlineTekAssigned(8), and the modem is considered as
'offline' for other values for cdxCmtsCmStatusValue.
|
| cdxIfCmtsCmStatusAvgOnlineTime |
.1.3.6.1.4.1.9.9.116.1.3.2.1.5 |
|
The average period of time the modem stayed 'online' over
the time period from the modem's first ranging message
received by CMTS until now.
The modem is considered as 'online' when the value for
cdxCmtsCmStatusValue is any of the values: online(5),
onlineNetAccessDisabled(6), onlineKekAssigned(7), and
onlineTekAssigned(8), and the modem is considered as
'offline' for other values for cdxCmtsCmStatusValue.
|
| cdxIfCmtsCmStatusMaxOnlineTime |
.1.3.6.1.4.1.9.9.116.1.3.2.1.6 |
|
The maximum period of time the modem stayed 'online' over
the time period from the modem's first ranging message
received by CMTS until now.
The modem is considered as 'online' when the value for
cdxCmtsCmStatusValue is any of the values: online(5),
onlineNetAccessDisabled(6), onlineKekAssigned(7), and
onlineTekAssigned(8), and the modem is considered as
'offline' for other values for cdxCmtsCmStatusValue.
|
| cdxIfCmtsCmStatusMinOfflineTime |
.1.3.6.1.4.1.9.9.116.1.3.2.1.7 |
|
The minimum period of time modem stayed 'offline' over
the time period from the modem's first ranging message
received by CMTS until now.
The modem is considered as 'online' when the value for
cdxCmtsCmStatusValue is any of the values: online(5),
onlineNetAccessDisabled(6), onlineKekAssigned(7), and
onlineTekAssigned(8), and the modem is considered as
'offline' for other values for cdxCmtsCmStatusValue.
|
| cdxIfCmtsCmStatusAvgOfflineTime |
.1.3.6.1.4.1.9.9.116.1.3.2.1.8 |
|
The average period of time the modem stayed 'offline' over
the time period from the modem's first ranging message
received by CMTS until now.
The modem is considered as 'online' when the value for
cdxCmtsCmStatusValue is any of the values: online(5),
onlineNetAccessDisabled(6), onlineKekAssigned(7), and
onlineTekAssigned(8), and the modem is considered as
'offline' for other values for cdxCmtsCmStatusValue.
|
| cdxIfCmtsCmStatusMaxOfflineTime |
.1.3.6.1.4.1.9.9.116.1.3.2.1.9 |
|
The maximum period of time the modem stayed 'offline' over
the time period from the modem's first ranging message
received by CMTS until now.
The modem is considered as 'online' when the value for
cdxCmtsCmStatusValue is any of the values: online(5),
onlineNetAccessDisabled(6), onlineKekAssigned(7), and
onlineTekAssigned(8), and the modem is considered as
'offline' for other values for cdxCmtsCmStatusValue.
|
| cdxIfCmtsCmStatusDynSidCount |
.1.3.6.1.4.1.9.9.116.1.3.2.1.10 |
|
The number of active dynamic SIDs on this modem.
Prior to getting the assigned the Service Flow IDs(SFID)
the CM must must complete a number of protocol
transactions. The CMTS assigns a temporary Service ID
(SID) to complete these steps.
|
| cdxIfCmtsCmStatusAddlInfo |
.1.3.6.1.4.1.9.9.116.1.3.2.1.11 |
|
This object indicates additional attributes regarding
the CM.
1. noisyPlant indicates that the CM connection is noisy.
2. modemPowerMaxOut indicates that the modem has reached
its maximum power level.
A bit of of this object is set to 1 if the condition
indicated by the bit is satisfied.
Note that BITS are encoded most significant bit
first.
|
| cdxIfCmtsCmStatusOnlineTimesNum |
.1.3.6.1.4.1.9.9.116.1.3.2.1.12 |
|
The number of times that the modem changes the connectivity
state from 'offline' to 'online' over the time period from
the modem's first ranging message received by CMTS until now.
The modem is considered as 'online' when the value for
cdxCmtsCmStatusValue is any of the values: online(5),
onlineNetAccessDisabled(6), onlineKekAssigned(7), and
onlineTekAssigned(8), and the modem is considered as 'offline'
for other values for cdxCmtsCmStatusValue.
The value of this object is reset to 0 if the value in
cdxIfCmtsCmStatusLastResetTime is changed.
|
| cdxIfCmtsCmStatusLastResetTime |
.1.3.6.1.4.1.9.9.116.1.3.2.1.13 |
|
The last cable modem connectivity statistics reset time. If
the value of this object is '0', then the cable modem
connectivity statistics had not been reset.
|
| cdxCmtsCmOnOffTrapEnable |
.1.3.6.1.4.1.9.9.116.1.3.3.1.1 |
|
An indication of whether the cdxCmtsCmOnOffNotification
is enabled. The default value is false(2).
|
| cdxCmtsCmOnOffTrapInterval |
.1.3.6.1.4.1.9.9.116.1.3.3.1.2 |
|
The interval for cdxCmtsCmOnOffNotification sent by CMTS for
one online/offline state change if cdxCmtsCmOnOffTrapEnable
is true.
If there are more than one state changes to online/offline
for a cable modem during this interval, only one
cdxCmtsCmOnOffNotification is sent by CMTS for the first
state change to online and one cdxCmtsCmOnOffNotification
for the first state changing to offline if
cdxCmtsCmOnOffTrapEnable is true.
This is to avoid too many notifications sent for a cable
modem online/offline state changes during a short period
of time.
If the value is 0, then cdxCmtsCmOnOffNotification will be
sent for every state changes to online/offline for a cable
modem if cdxCmtsCmOnOffTrapEnable is true.
If cdxCmtsCmOnOffTrapEnable value changes from true to false
or from false to true, this value will remain no change as
before.
The default value is 600 seconds.
|
| cdxCmtsCmDefaultMaxCpes |
.1.3.6.1.4.1.9.9.116.1.3.3.1.3 |
|
The default maximum number of permitted CPEs per modem
in this cable interface. A modem can override this
value by setting the object cdxCmtsCmMaxCpeNumber
in the cdxCmtsCmTable.
The value 0 means no maximum limit.
Setting the value will not affect the already connected
CPEs to the modems in this cable interface.
|
| cdxCmtsCmTotal |
.1.3.6.1.4.1.9.9.116.1.3.3.1.4 |
|
The total count of cable modems on this cable mac interface
since boot.
|
| cdxCmtsCmActive |
.1.3.6.1.4.1.9.9.116.1.3.3.1.5 |
|
The count of cable modems that are active. Active cable
modems are recognized by the cdxCmtsCmStatusValue
other than offline(1).
|
| cdxCmtsCmRegistered |
.1.3.6.1.4.1.9.9.116.1.3.3.1.6 |
|
The count of cable modems that are registered and online
on this cable mac interface. Registered cable modems are
those with one of the following values.
registrationComplete(6) of docsIfCmtsCmStatusValue OR
either of online(12), kekRejected(10),
onlineKekAssigned(6),tekRejected(11), onlineTekAssigned(7)
of cdxCmtsCmStatusValue
|
| cdxCmtsCmChOverSerialNumber |
.1.3.6.1.4.1.9.9.116.1.3.5.1.1 |
|
Object which specifies a unique entry in the
table. A management station wishing to initiate a
channel override operation should use a pseudo-random
value for this object when creating or modifying an
instance of a cdxCmtsCmChOverEntry.
|
| cdxCmtsCmChOverMacAddress |
.1.3.6.1.4.1.9.9.116.1.3.5.1.2 |
|
The mac address of the cable modem that the CMTS instructs to
move to a new downstream and/or upstream channel.
This column must be set to a valid Mac address currently in
the CMTS in order for this entry's row status to be set to
active successfully.
|
| cdxCmtsCmChOverDownFrequency |
.1.3.6.1.4.1.9.9.116.1.3.5.1.3 |
|
The new downstream frequency which the cable modem is
instructed to move to. The value 0 is to ask the CMTS not to
override the downstream frequency.
|
| cdxCmtsCmChOverUpChannelId |
.1.3.6.1.4.1.9.9.116.1.3.5.1.4 |
|
The new channel Id which the cable modem is instructed to
move to. The value -1 is to ask the CMTS not to override
the upstream channel Id.
|
| cdxCmtsCmChOverTrapOnCompletion |
.1.3.6.1.4.1.9.9.116.1.3.5.1.5 |
|
Specifies whether or not a cdxCmtsCmChOverNotification
should be issued on completion of the operation. If such a
notification is desired, it is the responsibility of the
management entity to ensure that the SNMP administrative model
is configured in such a way as to allow the notification to be
delivered.
|
| cdxCmtsCmChOverOpInitiatedTime |
.1.3.6.1.4.1.9.9.116.1.3.5.1.6 |
|
The value of sysUpTime at which the operation was initiated.
Since it is possible to have more than one entry in this
table for a cable modem, this object can help to distinguish
the entries for the same cable modem.
|
| cdxCmtsCmChOverState |
.1.3.6.1.4.1.9.9.116.1.3.5.1.7 |
|
The status of the specified channel override operation.
The enumerations are:
messageSent(1): the CMTS has sent a RNG-RSP message
with channel override to the cable modem.
commandNotActive(2): the command is not in active mode
due to this entry's row status is not
in active yet.
noOpNeed(3): The downstream frequency and the upstream
channel Id in this entry are the same as
original ones when this entry's row status
is set to active, so CMTS does not need to
do any operation.
modemNotFound(4): The modem is not found in the CMTS
at the time when the command becomes
active.
waitToSendMessage(5): specified the operation is active
and CMTS is waiting to send
a RNG-RSP message with channel
override to the cable modem.
timeOut(6): specified the operation is timed out.
That is, the CMTS cannot send a RNG-RSP message
with channel override to the cable modem within
the time specified in the object of
cdxCmtsCmChOverTimeExpiration.
The possible reason is that the cable modem
does not repeat the initial ranging.
The possible state change diagram is as below:
[commandNotActive ->] waitToSendMessage ->
messageSent or timeOut.
[commandNotActive ->] noOpNeeded or modemNotFound.
|
| cdxCmtsCmChOverRowStatus |
.1.3.6.1.4.1.9.9.116.1.3.5.1.8 |
|
The status of this table entry.
This value for cdxCmtsCmChOverMacAddress must be valid Mac
address currently in the CMTS in order for the row
status to be set to active successfully.
Once the row status becomes active and state becomes
waitToSendMessage, the entry cannot not be changed except
to delete the entry by setting the row status to destroy(6)
and since the operation cannot be stopped, the destroy(6)
will just cause the SNMP agent to hide the entry from
application and the SNMP agent will delete the entry
right after the operation is completed.
|
| cdxCmtsCmMaxCpeNumber |
.1.3.6.1.4.1.9.9.116.1.3.6.1.1 |
|
The maximum number of permitted CPEs connecting to the
modem.
The value -1 means to use the default value of maximum
hosts per modem in the CMTS cable interface which the modem
connects to and the value is defined in
cdxCmtsCmDefaultMaxCpes in the cdxCmtsMacExtTable.
The value 0 means no maximum limit.
Setting the value will not affect the already connected
CPEs to the modem.
|
| cdxCmtsCmCurrCpeNumber |
.1.3.6.1.4.1.9.9.116.1.3.6.1.2 |
|
The current number of CPEs connecting to the modem.
The value 0 means no hosts connecting to the modem.
|
| cdxIfUpChannelWidth |
.1.3.6.1.4.1.9.9.116.1.4.1.1.1 |
|
The lower bound for the bandwidth of this upstream channel.
The bandwidth specified by docsIfUpChannelWidth is used as
the upper bound of the upstream channel. The two objects,
docsIfUpChannelWidth and cdxIfUpChannelWidth, in
conjunction, define the upstream channel width range to be
used for the automated spectrum management.
This object returns 0 if the channel width is undefined
or unknown.
For those upstreams in the linecards which do not have the
automated spectrum management feature, this channel width
is undefined and always has value 0.
|
| cdxIfUpChannelModulationProfile |
.1.3.6.1.4.1.9.9.116.1.4.1.1.2 |
|
The secondary modulation profile for the upstream channel.
This should be a QPSK modulation profile if the primary profile
is QAM-16. The CMTS will switch from primary profile (QAM16) to
secondary profile (QPSK) depending on the noise level of a
particular spectrum band.
This is an entry identical to the docsIfModIndex in the
docsIfCmtsModulationTable that describes this channel.
This channel is further instantiated there by a grouping
of interval usage codes which together fully describe the
channel modulation. This object returns 0 if the
docsIfCmtsModulationTable does not exist or is empty.
|
| cdxIfUpChannelCmTotal |
.1.3.6.1.4.1.9.9.116.1.4.1.1.3 |
|
The total count of cable modems on this upstream channel
since boot.
|
| cdxIfUpChannelCmActive |
.1.3.6.1.4.1.9.9.116.1.4.1.1.4 |
|
The count of cable modems that are active.Active cable
modems are recognized by the cdxCmtsCmStatusValue other
than offline(1).
|
| cdxIfUpChannelCmRegistered |
.1.3.6.1.4.1.9.9.116.1.4.1.1.5 |
|
The count of cable modems that are registered and online
on this upstream. Registered cable modems are those
with one of the following values:
registrationComplete(6) of docsIfCmtsCmStatusValue OR
online(12), kekRejected(10), onlineKekAssigned(6),
tekRejected(11),onlineTekAssigned(7) of
cdxCmtsCmStatusValue.
|
| cdxIfUpChannelInputPowerLevel |
.1.3.6.1.4.1.9.9.116.1.4.1.1.6 |
|
The Upstream Input power level at the CMTS interface.
This is the expected power level and is different from the
actual power received. If not configured the default value
is 0 dBmV and is also the optimum setting power level for
the upstream. For FPGA line cards, the valid range
is <-10 to 10> dBmV and for ASIC Line cards, it is
<-10 to 25> dBmV.
|
| cdxIfUpChannelAvgUtil |
.1.3.6.1.4.1.9.9.116.1.4.1.1.7 |
|
The average percentage of upstream channel utilization.
This item indicates the running average of percent
channel utilization in CMTS upstream Mac scheduler.
|
| cdxIfUpChannelAvgContSlots |
.1.3.6.1.4.1.9.9.116.1.4.1.1.8 |
|
The average percentage of contention mini-slots. This
item indicates the running average of percent
contention mini-slots in CMTS upstream Mac scheduler.
|
| cdxIfUpChannelRangeSlots |
.1.3.6.1.4.1.9.9.116.1.4.1.1.9 |
|
The average percentage of initial ranging mini-slots.
This item indicates the running average of percent
initial ranging mini-slots in CMTS upstream Mac
scheduler.
|
| cdxIfUpChannelNumActiveUGS |
.1.3.6.1.4.1.9.9.116.1.4.1.1.10 |
|
This object indicates the number of active
Unsolicited Grant Service (UGS) on a given upstream.
This would be used for the user to evaluate traffic
load at any given time of the day.
The Unsolicited Grant Service (UGS) is designed to
support real-time service flows that generate fixed
size data packets on a periodic basis.
|
| cdxIfUpChannelMaxUGSLastOneHour |
.1.3.6.1.4.1.9.9.116.1.4.1.1.11 |
|
This object indicates the maximum number of
Unsolicited Grant Service (UGS) allocated on a
given upstream in the last one hour. This would be
used for the user to evaluate traffic load at any
given time of the day.
The Unsolicited Grant Service (UGS) is designed to
support real-time service flows that generate fixed
size data packets on a periodic basis.
|
| cdxIfUpChannelMinUGSLastOneHour |
.1.3.6.1.4.1.9.9.116.1.4.1.1.12 |
|
This object indicates the minimum number of
Unsolicited Grant Service (UGS) allocated on a
given upstream in the last one hour. This would be
used for the user to evaluate traffic load at any
given time of the day.
The Unsolicited Grant Service (UGS) is designed to
support real-time service flows that generate fixed
size data packets on a periodic basis.
|
| cdxIfUpChannelAvgUGSLastOneHour |
.1.3.6.1.4.1.9.9.116.1.4.1.1.13 |
|
This object indicates the average number of
Unsolicited Grant Service (UGS) allocated on a
given upstream in the last one hour. This would be
used for the user to evaluate traffic load at any
given time of the day.
The Unsolicited Grant Service (UGS) is designed to
support real-time service flows that generate fixed
size data packets on a periodic basis.
|
| cdxIfUpChannelMaxUGSLastFiveMins |
.1.3.6.1.4.1.9.9.116.1.4.1.1.14 |
|
This object indicates the maximum number of
Unsolicited Grant Service (UGS) allocated on a
given upstream in the last five minutes. This would
be used for the user to evaluate traffic load at
any given time of the day.
The Unsolicited Grant Service (UGS) is designed to
support real-time service flows that generate fixed
size data packets on a periodic basis.
|
| cdxIfUpChannelMinUGSLastFiveMins |
.1.3.6.1.4.1.9.9.116.1.4.1.1.15 |
|
This object indicates the minimum number of
Unsolicited Grant Service (UGS) allocated on a
given upstream in the last five minutes. This would
be used for the user to evaluate traffic load at
any given time of the day.
The Unsolicited Grant Service (UGS) is designed to
support real-time service flows that generate fixed
size data packets on a periodic basis.
|
| cdxIfUpChannelAvgUGSLastFiveMins |
.1.3.6.1.4.1.9.9.116.1.4.1.1.16 |
|
This object indicates the average number of
Unsolicited Grant Service (UGS) allocated on a
given upstream in the last five minutes. This would
be used for the user to evaluate traffic load at
any given time of the day.
The Unsolicited Grant Service (UGS) is designed to
support real-time service flows that generate fixed
size data packets on a periodic basis.
|
