1 module packetcable-traffic-profile
3 namespace "urn:opendaylight:flow:traffic-profile";
6 organization "OpenDaylight Project";
10 "This module contains a collection of groupings and
11 data definition statements related to the configuration
12 of Traffic Profiles.";
14 revision "2014-08-08" {
15 description "Initial revision of packetcable traffic profile";
20 typedef tp-reference {
21 type instance-identifier;
30 "32-bit IEEE floating point number" ;
33 typedef traffic-profile-type {
36 There are four different ways to express a traffic profile. The traffic profile can be expressed via a FlowSpec, a DOCSIS Service Class Name, DOCSIS-specific parameters or Upstream Drop. The four methods are distinguished via a different S-Type value in the Traffic Profile (S-Num = 7) object. S-Type of 1 indicates the object contains a traffic profile specified in RSVP FlowSpec format. S-Type of 2 indicates the object contains a traffic profile specified in DOCSIS Service Class Name format. S-Type of 3 - 8 indicates the object contains a traffic profile that is specified via DOCSIS-specific parameters. S-Type of 9 indicates the object contains a traffic profile specified in an Upstream Drop format.
38 All Traffic Profiles utilize 'replace' semantics, meaning that the envelopes present in this Traffic Profile replace all existing envelopes associated with the Gate and corresponding Service Flow. Thus, all traffic parameters associated with a given Gate MUST be included in every message that includes a Traffic Profile. The traffic profile format (RSVP FlowSpec, DOCSIS Service Class Name, DOCSIS-specific parameters, Upstream Drop) for a specific envelope MUST remain constant and unchanged throughout the life of the gate.
40 All Traffic Profiles share a common field known as the Envelope Field. This field is a bit field that signals the envelope types (i.e., Authorized, Reserved, and Committed) that are present in the object. A value of 1 in a given bit field indicates that the envelope type is present in the Traffic Profile.
42 • Bit 0: Authorized Envelope
44 • Bit 1: Reserved Envelope
46 • Bit 2: Committed Envelope
48 Thus a bit pattern of 001 (or 0x01) indicates the presence of only the Authorized Envelope, while a value of 111 (or 0x7) indicates the presence of all three envelopes. Only the following values are legal: 001, 011 and 111; the Envelope Field MUST be set to one of these three legal values. Further limitations on the value of the Envelope Field may be a function of the current state of the Gate. Refer to Section 6.2 for more information.
50 For the Traffic Profile formats that allow multiple sets of envelope parameters, the mapping of envelope parameter sets follows one of the following methods:
52 • If all of the envelope types that are indicated in the envelope field share a common set of envelope parameters, then the PDP SHOULD ensure that exactly one set of envelope parameters are present in the traffic profile. This allows for the most efficient transmission and processing of the Traffic Profile throughout the system.
54 • Otherwise, the PDP MUST ensure that exactly one set of envelope parameters is included for each of the envelope types that are indicated in the envelope field. The proper order of the envelope parameter sets is shown in the appropriate message diagram in Sections 6.4.2.1 and 6.4.2.3 thru 6.4.2.7.8.
56 While all Traffic Profiles end up providing QoS on the access network, it is important to note several subtle differences between the signaling mechanisms. As noted previously, the conversion of a FlowSpec (S-Type 1) to DOCSIS parameters by the CMTS is generally less efficient than specifying the DOCSIS parameters themselves. That said, specifying DOCSIS parameters explicitly (S-Types 3-7) is not a panacea either, the QoS MIB only logs QoS information about named Service Flows in its ServiceFlowLogTable. Thus, only flows created via S-Type 2 will have logged QoS information in this table. For some this may not be a major issue, but for debugging and just general operational tracking this subtlety should be taken into account by operators and Application Manager vendors evaluating the Traffic Profile signaling alternatives provided by this specification.
60 enum flowspec { value 0; }
61 enum docsis-service-class-name { value 1; }
62 enum docsis-specific-parameterization { value 2; }
63 enum upstream-drop { value 3; }
65 enum best-effort { value 4; }
66 enum unsolicited-grant-service { value 5; }
67 enum unsolicited-grant-service-with-activity-detection { value 6; }
68 enum non-real-time-polling-service { value 7; }
69 enum real-time-polling-service { value 8; }
70 enum downstream-service { value 9; }
75 grouping flowspec-envelope {
77 The values r, b, p, m, M, R, and s are defined and described
80 • Bucket Depth (b), bytes
81 • Bucket Rate (r), bytes/second
82 • Maximum Datagram Size (M), bytes
83 • Minimum Policed Unit (m), bytes
84 • Peak Rate (p), bytes/second RSpec Parameters:
85 • Reserved Rate (R), bytes/second
86 • Slack Term (S), microseconds
87 The parameter mapping, roughly approximated, involves the following associations for DOCSIS upstream BE (Best-Effort) and downstream Controlled Load Service Flows. The actual mapping procedure would involve normalizing these parameters to account for Layer 2 and Layer 3 header considerations.
88 • TSpec Bucket Depth (b) ~= DOCSIS Maximum Traffic Burst
89 • TSpec Maximum Datagram Size (M) ~= <not required by DOCSIS >
90 • TSpec Minimum Policed Unit (m) ~= DOCSIS Assumed Minimum Reserved Rate Packet Size
91 • TSpec Bucket Rate (r) ~= DOCSIS Minimum Reserved Rate
92 • TSpec Peak Rate (p) ~= DOCSIS Maximum Sustained Rate and, for DOCSIS 3.0 only, DOCSIS Downstream Peak Traffic Rate
93 For downstream Guaranteed service flows, the RSpec parameters are added to provide latency and reservation guarantees.
94 • TSpec Bucket Depth (b) ~= DOCSIS Maximum Traffic Burst
95 • TSpec Maximum Datagram Size (M) ~= <not required by DOCSIS >
96 • TSpec Minimum Policed Unit (m) ~= DOCSIS Assumed Minimum Reserved Rate Packet Size
97 • TSpec Bucket Rate (r) ~= DOCSIS Minimum Reserved Rate and DOCSIS Maximum Sustained Rate
98 • TSpec Peak Rate (p) ~= For DOCSIS 3.0 only, DOCSIS Downstream Peak Traffic Rate
99 • RSpec Reserved Rate (R) ~= <not required by DOCSIS>
100 • RSpec Slack Term ~= DOCSIS Downstream Latency
101 The parameter mapping, roughly approximated, involves the following associations for DOCSIS UGS Service Flows.
102 • TSpec Bucket Depth (b) = TSpec Maximum Datagram Size (M) = TSpec Minimum Policed Unit (m) ~= DOCSIS Unsolicited Grant Size
103 • TSpec Bucket Rate (r) = TSpec Peak Rate (p) = RSpec Reserved Rate (R) ~= used to calculate Nominal Grant Interval
104 • RSpec Slack Term ~= DOCSIS Tolerated Grant Jitter
105 Similarly, the following associations apply for DOCSIS Real-Time Polling Service Flows.
106 • TSpec Bucket Depth (b) ~= DOCSIS Maximum Traffic Burst
107 • TSpec Maximum Datagram Size (M) ~= <not required by DOCSIS >
108 • TSpec Bucket Rate (r) ~= DOCSIS Maximum Sustained Rate and DOCSIS Minimum Reserved Traffic Rate
109 • RSpec Reserved Rate (R) ~= used to calculate the Polling Interval
110 • RSpec Slack Term ~= Tolerated Polling Jitter
112 Token Bucket Rate [r] (encoded as IEEE floating point)
113 0x461C4000 (10,000 Bps)
114 Token Bucket Size [b] (encoded as IEEE floating point)
115 0x43480000 (200 bytes)
116 Peak Data Rate [p] (encoded as IEEE floating point)
117 0x461C4000 (10,000 Bps)
118 Minimum Policed Unit [m]
119 0x000000C8 (200 bytes)
120 Maximum Packet Size [M]
121 0x000000C8 (200 bytes)
122 Rate [R] (encoded as IEEE floating point)
123 0x461C4000 (10,000 Bps)
129 leaf token-bucket-rate {
131 description "[r] (IEEE floating point number
136 leaf token-bucket-size {
138 description "[p] IEEE floating point number";
141 leaf peak-data-rate {
143 description "[m] IEEE floating point number
149 leaf minimum-policed-unit {
151 description "[m] (integer)";
155 leaf maximum-packet-size {
157 description "[M] (integer)";
162 description "[R] (IEEE floating point number)";
167 description "[S] (integer)";
172 grouping default-envelope {
173 leaf traffic-priority {
177 Traffic Priority is a 1-byte unsigned integer field specifying the relative priority assigned to the Service Flow in comparison with other flows. This field is fully defined in section C.2.2.5.1 of [1]. A default Traffic Priority of 0 SHOULD be used if a specific Traffic Priority value is not required.
189 leaf request-transmission-policy {
192 Request/Transmission Policy is a 4-byte bit field as defined in section C.2.2.6.3 of [1]. A default Request/Transmission policy of 0 SHOULD be used if a specific Request/Transmission Policy value is not required.
196 leaf maximum-sustained-traffic-rate {
199 Maximum Sustained Traffic Rate is a 4-byte unsigned integer field specifying the rate parameter, in bits/sec, for [1]. A value of 0 indicates that no explicitly-enforced Maximum Sustained Rate is requested. A default Maximum Sustained Traffic Rate of 0 SHOULD be used if a specific Maximum Sustained Traffic Rate is not required.
204 leaf maximum-traffic-burst {
207 Maximum Traffic Burst is a 4-byte unsigned integer field specifying the token bucket size, in bytes, for a token- bucket-based rate limit for this Service Flow. This field is fully defined in section C.2.2.5.3 of [1]. A default Maximum Traffic Burst of 3044 bytes SHOULD be used if a specific Maximum Traffic Burst is not required. The value of this parameter has no effect unless a non-zero value has been provided for the Maximum Sustained Traffic Rate parameter.
211 leaf minimum-reserved-traffic-rate {
215 Minimum Reserved Traffic Rate is a 4-byte unsigned integer field specifying the minimum rate, in bits/sec, reserved for this Service Flow. This field is fully defined in section C.2.2.5.4 of [1]. A default Minimum Reserved Traffic Rate of 0 SHOULD be used if a specific Minimum Reserved Traffic Rate is not required.
220 leaf assumed-minimum-reserved-traffic-rate-packet-size {
224 Assumed Minimum Reserved Traffic Rate Packet Size is a 2-byte unsigned integer field specifying an assumed minimum packet size, in bytes, for which the Minimum Reserved Traffic Rate will be provided for this flow. This field is fully defined in section C.2.2.5.5 of [1]. A default Assumed Minimum Reserved Traffic Rate Packet Size of 0 SHOULD be used if a specific Assumed Minimum Reserved Traffic Rate Packet size is not required. Upon receipt of a value of 0 the CMTS MUST utilize its implementation-specific default size for this parameter, not 0 bytes.
229 leaf maximum-concatenated-burst {
233 Maximum Concatenated Burst is a 2-byte unsigned integer specifying the maximum concatenated burst (in bytes) which a Service Flow is allowed. This field is fully defined in section C.2.2.6.1 of [1]. A value of 0 means there is no limit. A default Maximum Concatenated Burst of 1522 bytes SHOULD be used if a specific Maximum Concatenated Burst is not required.
238 leaf upstream-peak-traffic-rate {
242 Upstream Peak Traffic Rate is a 4-byte unsigned integer specifying the Peak traffic rate (in bits per second) which a
243 Service Flow is allowed. This field is fully defined in section C.2.2.5.10.1 of [1].
248 leaf required-attribute-mask {
252 Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS MUST ignore the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in section C.2.2.3.6 of [1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by forbidding certain attributes. This field is fully defined in section C.2.2.3.7 of [1]. The CMTS is free to assign the service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for this service flow. This field is fully described in section 'Service Flow Attribute Aggregation Rule Mask' of [1]. As described in that section a default Attribute Aggregation Rule Mask of 0 SHOULD be used if specific Attribute Aggregation Rules are not required.
257 leaf forbidden-attribute-mask {
261 Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS MUST ignore the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in section C.2.2.3.6 of [1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by forbidding certain attributes. This field is fully defined in section C.2.2.3.7 of [1]. The CMTS is free to assign the service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for this service flow. This field is fully described in section 'Service Flow Attribute Aggregation Rule Mask' of [1]. As described in that section a default Attribute Aggregation Rule Mask of 0 SHOULD be used if specific Attribute Aggregation Rules are not required.
265 leaf attribute-aggregation-rule-mask {
269 Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS MUST ignore the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in section C.2.2.3.6 of [1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by forbidding certain attributes. This field is fully defined in section C.2.2.3.7 of [1]. The CMTS is free to assign the service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for this service flow. This field is fully described in section 'Service Flow Attribute Aggregation Rule Mask' of [1]. As described in that section a default Attribute Aggregation Rule Mask of 0 SHOULD be used if specific Attribute Aggregation Rules are not required.
273 leaf minimum-buffer {
277 Minimum Buffer is a 4-byte unsigned integer parameter that defines a lower limit for the size of the buffer that is to be provided for a service flow. This field is fully defined in section C.2.2.5.11.3 of [1]. If this parameter is omitted, the Minimum Buffer defaults to a value of 0, which indicates that there is no lower limit.
285 Target Buffer is a 4-byte unsigned integer parameter that defines a desired value for the size of the buffer that is to be provided for a service flow. This field is fully defined in section C.2.2.5.11.4 of [1]. If this parameter is omitted or set to a value of 0, the device selects any buffer size within the range of the Minimum and Maximum Buffers, via a vendor-specific algorithm.
290 leaf maximum-buffer {
294 Maximum Buffer is a 4-byte unsigned integer parameter that defines an upper limit for the size of the buffer that is to be provided for a service flow. This field is fully defined in section C.2.2.5.11.5 of [1]. If this parameter is omitted, the Maximum Buffer defaults to a value of no limit.
301 grouping ugs-envelope {
302 leaf request-transmission-policy {
305 Request/Transmission Policy is a 4-byte bit field as defined in section C.2.2.6.3 of [1]. Note: for this Service Flow Scheduling Type there is no default value for Request/Transmission Policy and all values (including 0) have meaning in DOCSIS. Bit 9 in the Request/Transmission Policy enables/disables the use of segment headers. A segment header is 8 bytes in length. It MUST be accounted for in the Unsolicited Grant Size parameter when segment header usage is enabled. The CMTS MUST ignore Bit 9 in the Request/Transmission Policy if the cable modem associated with the service flow is operating in DOCSIS 1.1 or 2.0 mode. For more information on segment headers and their use please see section 6.3 of [1].
309 leaf unsolicited-grant-size {
312 Unsolicited Grant Size is a 2-byte unsigned integer field specifying the grant size (in bytes) as defined in section C.2.2.6.6 of [1]. There is no default value of Unsolicited Grant Size.
316 leaf grants-interval {
319 Grants per Interval is a 1-byte unsigned integer field specifying the number of grants per Nominal Grant Interval as defined in section C.2.2.6.9 of [1]. There is no default value of Grants per Interval, but a value of 1 is recommended.
329 leaf nominal-grant-interval {
332 Nominal Grant Interval is a 4-byte unsigned integer field specifying the nominal time between successive data grant opportunities for this Service Flow (in units of microseconds) as defined in section C.2.2.6.7 of [1].
337 leaf tolerated-grant-jitter {
340 Tolerated Grant Jitter is a 4-byte unsigned integer field specifying the maximum amount of time that transmission opportunities may be delayed from the nominal periodic schedule (in units of microseconds) as defined in section C.2.2.6.8 of [1]. The minimum allowed value is 800. If the CMTS receives a Gate-Set message with Tolerated Grant Jitter less than 800, the CMTS MUST reply with a Gate-Set-Err message with a PacketCable Error-Code of 'Invalid Field Value in Object'. There is no default value of Nominal Grant Interval. There is no default value for Tolerated Grant Jitter.
344 leaf required-attribute-mask {
347 Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS MUST ignore the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in section C.2.2.3.6 of [1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by forbidding certain attributes. This field is fully defined in section C.2.2.3.7 of [1]. The CMTS is free to assign the service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for this service flow. This field is fully described in section 'Service Flow Attribute Aggregation Rule Mask' of [1]. As described in that section, a default Attribute Aggregation Rule Mask of 0 SHOULD be used if specific Attribute Aggregation Rules are not required.
351 leaf forbidden-attribute-mask {
354 Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS MUST ignore the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in section C.2.2.3.6 of [1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by forbidding certain attributes. This field is fully defined in section C.2.2.3.7 of [1]. The CMTS is free to assign the service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for this service flow. This field is fully described in section 'Service Flow Attribute Aggregation Rule Mask' of [1]. As described in that section, a default Attribute Aggregation Rule Mask of 0 SHOULD be used if specific Attribute Aggregation Rules are not required.
358 leaf attribute-aggregation-rule-mask {
361 Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS MUST ignore the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in section C.2.2.3.6 of [1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by forbidding certain attributes. This field is fully defined in section C.2.2.3.7 of [1]. The CMTS is free to assign the service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for this service flow. This field is fully described in section 'Service Flow Attribute Aggregation Rule Mask' of [1]. As described in that section, a default Attribute Aggregation Rule Mask of 0 SHOULD be used if specific Attribute Aggregation Rules are not required.
369 grouping us-envelope {
370 leaf us-traffic-priority {
373 Traffic Priority is a 1-byte unsigned integer field specifying the relative priority assigned to the Service Flow in comparison with other flows. This field is fully defined in section C.2.2.5.1 of [1]. A default Traffic Priority of 0 SHOULD be used if a specific Traffic Priority value is not required.
378 leaf downstream-resequencing {
381 DOCSIS 3.0 service flows. This field is fully defined in section C.2.2.7.3 of [1]. The CMTS MUST honor the requested Downstream Resequencing operation for all Gate requests. It is possible that the CMTS may receive conflicting downstream resequencing direction by the AM for Multicast Gate requests (e.g., multiple Multicast Gate requests for the same Multicast destination but with different downstream resequencing operation). In such a case the CMTS MUST either honor the Multicast Gate request or reject it with error code 35 (Multicast Gate Downstream Resequencing mismatch). For a Multicast Gate, the CMTS MUST ignore the Downstream Resequencing object if the cable modem associated with the service flow is operating in MDF disabled mode. The CMTS MUST ignore the Downstream Resequencing object if the cable modem associated with the service flow is operating in pre-3.0 DOCSIS mode. DOCSIS 3.0 introduced the concept of downstream channel bonding where the CMTS can simultaneously transmit on multiple channels. Downstream channels may not all have the same amount of latency such that two packets scheduled simultaneously by the CMTS may not arrive simultaneously at the cable modem. The CMTS can insert sequence numbers in each DOCSIS packet header to allow the cable modem to re- order out of sequence packets. The cable modem will hold higher numbered packets while waiting for lower numbered packets to arrive. The maximum wait time is 18ms. Applications that can tolerate lost packets or applications that cannot tolerate packet latency of up to 18ms can disable the use of sequence numbers by setting the Downstream Resequencing value to 1.
392 leaf maximum-sustained-traffic-rate {
395 Maximum Sustained Traffic Rate is a 4-byte unsigned integer field specifying the rate parameter, in bits/sec, for a token-bucket-based rate limit for this Service Flow. This field is fully defined in section C.2.2.5.2 of [1]. A value of 0 indicates that no explicitly-enforced Maximum Sustained Rate is requested. A default Maximum Sustained Traffic Rate of 0 SHOULD be used if a specific Maximum Sustained Traffic Rate is not required.
400 leaf maximum-traffic-burst {
403 Maximum Traffic Burst is a 4-byte unsigned integer field specifying the token bucket size, in bytes, for a token- bucket-based rate limit for this Service Flow. This field is fully defined in section C.2.2.5.3 of [1]. A default Maximum Traffic Burst of 3044 bytes SHOULD be used if a specific Maximum Traffic Burst is not required. The value of this parameter has no effect unless a non-zero value has been provided for the Maximum Sustained Traffic Rate parameter.
408 leaf minimum-reserved-traffic-rate {
411 Minimum Reserved Traffic Rate is a 4-byte unsigned integer field specifying the minimum rate, in bits/sec, reserved for this Service Flow. This field is fully defined in section C.2.2.5.4 of [1]. A default Minimum Reserved Traffic Rate of 0 SHOULD be used if a specific Minimum Reserved Traffic Rate is not required.
416 leaf assumed-minimum-reserved-traffic-rate-packet-size {
419 Assumed Minimum Reserved Traffic Rate Packet Size is a 2-byte unsigned integer field specifying an assumed minimum packet size, in bytes, for which the Minimum Reserved Traffic Rate will be provided for this flow. This field is fully defined in section C.2.2.5.5 of [1]. A default Assumed Minimum Reserved Traffic Rate Packet Size of 0 SHOULD be used if a specific Assumed Minimum Reserved Traffic Rate Packet size is not required. Upon receipt of a value of 0 the CMTS MUST utilize its implementation-specific default size for this parameter, not 0 bytes.
432 leaf maximum-downstream-latency {
435 Maximum Downstream Latency is a 4-byte unsigned integer field specifying the maximum latency between reception of a packet on the CMTS's NSI and the forwarding of the packet on its RF interface as defined in section C.2.2.7.1 of [1]. A default Maximum Downstream Latency of 0 SHOULD be used if a specific Maximum Downstream Latency is not required. Upon receipt of a value of 0, the CMTS MUST NOT include this parameter in its DOCSIS signaling for this Service Flow.
441 leaf downstream-peak-traffic-rate {
444 Downstream Peak Traffic Rate is a 4-byte unsigned integer field, specifying the rate parameter P of a token-bucket- based peak rate limiter for packets of a downstream service flow. Configuring this peak rate parameter permits an operator to define a Maximum Burst value for the Downstream Maximum Sustained Rate much larger than a maximum packet size, but still limit the burst of packets consecutively transmitted for a service flow. The Downstream Peak Traffic Rate parameter is fully defined in section C.2.2.7.2 of [1]. The CMTS MUST NOT include this parameter in its DOCSIS signaling for this service flow if a value of 0 is supplied, if the cable modem for which the Gate applies is not provisioned in DOCSIS 3.0 mode, or if the CMTS does not support the enforcement of this value.
449 leaf required-attribute-mask {
452 Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS MUST ignore the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in section C.2.2.3.6 of [1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by forbidding certain attributes. This field is fully defined in section C.2.2.3.7 of [1]. The CMTS is free to assign the service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for this service flow. This field is fully described in section 'Service Flow Attribute Aggregation Rule Mask' of [1]. As described in that section a default Attribute Aggregation Rule Mask of 0 SHOULD be used if specific Attribute Aggregation Rules are not required.
457 leaf forbidden-attribute-mask {
460 Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS MUST ignore the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in section C.2.2.3.6 of [1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by forbidding certain attributes. This field is fully defined in section C.2.2.3.7 of [1]. The CMTS is free to assign the service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for this service flow. This field is fully described in section 'Service Flow Attribute Aggregation Rule Mask' of [1]. As described in that section a default Attribute Aggregation Rule Mask of 0 SHOULD be used if specific Attribute Aggregation Rules are not required.
465 leaf attribute-aggregation-rule-mask {
468 Attribute Masks define a specific set of attributes associated with a DOCSIS 3.0 service flow. The CMTS MUST ignore the bonded bit in the Required and Forbidden Attribute Mask objects if the cable modem associated with the service flow is operating in pre-3.0 DOCSIS mode. The Required Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by requiring certain attributes. This field is fully defined in section C.2.2.3.6 of [1]. The Forbidden Attribute Mask limits the set of channels and bonding groups to which the CMTS assigns the service flow by forbidding certain attributes. This field is fully defined in section C.2.2.3.7 of [1]. The CMTS is free to assign the service flow to any channel that satisfies the traffic profile if no channel is available that satisfies the Required Attribute Mask and Forbidden Attribute Mask for the service flow. The Attribute Aggregation Rule Mask provides guidance to the CMTS as to how it might use the attribute masks of individual channels to construct a dynamic bonding group for this service flow. This field is fully described in section 'Service Flow Attribute Aggregation Rule Mask' of [1]. As described in that section a default Attribute Aggregation Rule Mask of 0 SHOULD be used if specific Attribute Aggregation Rules are not required.
476 grouping traffic-profile-flowspec {
477 container f-authorized-envelope {
478 uses flowspec-envelope;
479 description "mandatory";
481 container f-reserved-envelope {
482 uses flowspec-envelope;
483 description "optional";
485 container f-committed-envelope {
486 uses flowspec-envelope;
487 description "optional";
492 grouping traffic-profile-docsis-service-class-name {
493 leaf service-class-name {
497 xxx - length 2 to 128?
499 The Service Class Name is MUST be 2-16 bytes of null-terminated ASCII string.
500 (Refer to section C.2.2.3.4 of [1]). This name MUST be padded with null bytes
501 to align on a 4-byte boundary.
507 grouping traffic-profile-best-effort {
508 container be-authorized-envelope {
509 uses default-envelope;
510 description "mandatory";
512 container bereserved-envelope {
513 uses default-envelope;
514 description "optional";
516 container be-committed-envelope {
517 uses default-envelope;
518 description "optional";
522 grouping traffic-profile-non-real-time-polling-service {
523 container nrtp-authorized-envelope {
524 uses default-envelope;
525 description "mandatory";
527 container nrtp-reserved-envelope {
528 uses default-envelope;
529 description "optional";
531 container nrtp-committed-envelope {
532 uses default-envelope;
533 description "optional";
538 grouping traffic-profile-real-time-polling-service {
539 container rtp-authorized-envelope {
540 uses default-envelope;
541 description "mandatory";
543 container rtp-reserved-envelope {
544 uses default-envelope;
545 description "optional";
547 container rtp-committed-envelope {
548 uses default-envelope;
549 description "optional";
553 grouping traffic-profile-unsolicited-grant-service {
554 container ugs-authorized-envelope {
556 description "mandatory";
558 container ugs-reserved-envelope {
560 description "optional";
562 container ugs-committed-envelope {
564 description "optional";
568 grouping traffic-profile-unsolicited-grant-service-with-activity-detection {
569 container usga-authorized-envelope {
571 description "mandatory";
573 container usga-reserved-envelope {
575 description "optional";
577 container usga-committed-envelope {
579 description "optional";
584 grouping traffic-profile-downstream-service {
585 container ds-authorized-envelope {
587 description "mandatory";
589 container ds-reserved-envelope {
591 description "optional";
593 container ds-committed-envelope {
595 description "optional";
600 grouping traffic-profile-upstream-drop {
603 grouping traffic-profile-docsis-specific-parameterization {
608 grouping traffic-profile-grouping {
610 type traffic-profile-type;
612 description "This attribute contains the type of upstream flow scheduling type.";
614 choice tp-type-choice {
615 case "flowspec" { uses traffic-profile-flowspec; }
616 case "docsis-service-class-name" { uses traffic-profile-docsis-service-class-name; }
617 case "docsis-specific-parameterization" { uses traffic-profile-docsis-specific-parameterization; }
618 case "upstream-drop" { uses traffic-profile-upstream-drop; }
619 case "best-effort" { uses traffic-profile-best-effort; }
620 case "unsolicited-grant-service" { uses traffic-profile-unsolicited-grant-service; }
621 case "unsolicited-grant-service-with-activity-detection" { uses traffic-profile-unsolicited-grant-service-with-activity-detection; }
622 case "non-real-time-polling-service" { uses traffic-profile-non-real-time-polling-service; }
623 case "real-time-polling-service" { uses traffic-profile-real-time-polling-service; }
624 case "downstream-service" { uses traffic-profile-downstream-service; }
629 // grouping taffic-profile-default-singleton-grouping {
630 // grouping flowspec { uses traffic-profile-flowspec; }
631 // grouping docsis-service-class-name { uses traffic-profile-docsis-service-class-name; }
632 // grouping docsis-specific-parameterization { uses traffic-profile-docsis-specific-parameterization; }
633 // grouping upstream-drop { uses traffic-profile-upstream-drop; }
634 // grouping best-effort { uses traffic-profile-best-effort; }
635 // grouping unsolicited-grant-service { uses traffic-profile-unsolicited-grant-service; }
636 // grouping unsolicited-grant-service-with-activity-detection { uses traffic-profile-unsolicited-grant-service-with-activity-detection; }
637 // grouping non-real-time-polling-service { uses traffic-profile-non-real-time-polling-service; }
638 // grouping real-time-polling-service { uses traffic-profile-real-time-polling-service; }
639 // grouping downstream-service { uses traffic-profile-downstream-service; }