packetcable-model/src/main/yang/packetcable-traffic-profile.yang

   1 module packetcable-traffic-profile
   2 {
   3     namespace "urn:opendaylight:flow:traffic-profile";
   4     prefix traffic;
   5
   6     organization "OpenDaylight Project";
   7     contact "TBD";
   8     description
   9          "This module contains a collection of groupings and
  10          data definition statements related to the configuration
  11          of Traffic Profiles.";
  12
  13     revision "2014-01-20" {
  14         description "Initial revision of packetcable traffic profile";
  15     }
  16
  17
  18
  19     typedef tp-reference {
  20     type instance-identifier;
  21     }
  22
  23
  24     typedef float {
  25        type binary {
  26          length "0..4";
  27        }
  28         description
  29         "32-bit IEEE floating point number" ;
  30     }
  31
  32     typedef traffic-profile-type {
  33             description
  34                 "
  35                 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.
  36
  37                 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.
  38
  39                 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.
  40
  41         • Bit 0: Authorized Envelope
  42
  43         • Bit 1: Reserved Envelope
  44
  45         • Bit 2: Committed Envelope
  46
  47                 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.
  48
  49                 For the Traffic Profile formats that allow multiple sets of envelope parameters, the mapping of envelope parameter sets follows one of the following methods:
  50
  51                 • 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.
  52
  53                 • 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.
  54
  55                 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.
  56     ";
  57
  58     type enumeration {
  59         enum flowspec { value 0; }
  60         enum docsis-service-class-name { value 1; }
  61         enum docsis-specific-paramterization { value 2; }
  62         enum upstream-drop { value 3; }
  63
  64         enum best-effort { value 4; }
  65         enum unsolicited-grant-service { value 5; }
  66         enum unsolicited-grant-service-with-activity-detection { value 6; }
  67         enum non-real-time-polling-service { value 7; }
  68         enum real-time-polling-service { value 8; }
  69         enum downstream-service { value 9; }
  70     }
  71
  72     }
  73
  74     grouping flowspec-envelope {
  75     description "
  76 The values r, b, p, m, M, R, and s are defined and described
  77
  78 TSpec Parameters:
  79 • Bucket Depth (b), bytes
  80 • Bucket Rate (r), bytes/second
  81 • Maximum Datagram Size (M), bytes
  82 • Minimum Policed Unit (m), bytes
  83 • Peak Rate (p), bytes/second RSpec Parameters:
  84 • Reserved Rate (R), bytes/second
  85 • Slack Term (S), microseconds
  86 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.
  87 • TSpec Bucket Depth (b) ~= DOCSIS Maximum Traffic Burst
  88 • TSpec Maximum Datagram Size (M) ~= <not required by DOCSIS >
  89 • TSpec Minimum Policed Unit (m) ~= DOCSIS Assumed Minimum Reserved Rate Packet Size
  90 • TSpec Bucket Rate (r) ~= DOCSIS Minimum Reserved Rate
  91 • TSpec Peak Rate (p) ~= DOCSIS Maximum Sustained Rate and, for DOCSIS 3.0 only, DOCSIS Downstream Peak Traffic Rate
  92 For downstream Guaranteed service flows, the RSpec parameters are added to provide latency and reservation guarantees.
  93 • TSpec Bucket Depth (b) ~= DOCSIS Maximum Traffic Burst
  94 • TSpec Maximum Datagram Size (M) ~= <not required by DOCSIS >
  95 • TSpec Minimum Policed Unit (m) ~= DOCSIS Assumed Minimum Reserved Rate Packet Size
  96 • TSpec Bucket Rate (r) ~= DOCSIS Minimum Reserved Rate and DOCSIS Maximum Sustained Rate
  97 • TSpec Peak Rate (p) ~= For DOCSIS 3.0 only, DOCSIS Downstream Peak Traffic Rate
  98 • RSpec Reserved Rate (R) ~= <not required by DOCSIS>
  99 • RSpec Slack Term ~= DOCSIS Downstream Latency
 100 The parameter mapping, roughly approximated, involves the following associations for DOCSIS UGS Service Flows.
 101 • TSpec Bucket Depth (b) = TSpec Maximum Datagram Size (M) = TSpec Minimum Policed Unit (m) ~= DOCSIS Unsolicited Grant Size
 102 • TSpec Bucket Rate (r) = TSpec Peak Rate (p) = RSpec Reserved Rate (R) ~= used to calculate Nominal Grant Interval
 103 • RSpec Slack Term ~= DOCSIS Tolerated Grant Jitter
 104 Similarly, the following associations apply for DOCSIS Real-Time Polling Service Flows.
 105 • TSpec Bucket Depth (b) ~= DOCSIS Maximum Traffic Burst
 106 • TSpec Maximum Datagram Size (M) ~= <not required by DOCSIS >
 107 • TSpec Bucket Rate (r) ~= DOCSIS Maximum Sustained Rate and DOCSIS Minimum Reserved Traffic Rate
 108 • RSpec Reserved Rate (R) ~= used to calculate the Polling Interval
 109 • RSpec Slack Term ~= Tolerated Polling Jitter
 110
 111     ";
 112
 113
 114         leaf token-bucket-rate {
 115                 type float;
 116                 description "[r] (IEEE floating point number ";
 117         }
 118         leaf token-bucket-size {
 119                 type float;
 120                 description "[p] IEEE floating point number";
 121         }
 122         leaf peak-data-rate {
 123                 type float;
 124                 description "[m] IEEE floating point number";
 125         }
 126         leaf minimum-policed-unit {
 127                 type uint32;
 128                 description "[m] (integer)";
 129         }
 130
 131         leaf maximum-packet-size {
 132                 type uint32;
 133                 description "[M] (integer)";
 134         }
 135         leaf rate {
 136                 type uint32;
 137                 description "[R] (IEEE floating point number)";
 138         }
 139         leaf slack-term {
 140                 type uint32;
 141                 description "[S] (integer)";
 142         }
 143     }
 144
 145     grouping default-envelope {
 146         leaf traffic-priority {
 147                 type uint8;
 148                 description
 149                         "
 150                         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.
 151                 ";
 152         }
 153         leaf reserved0 {
 154                 type uint8;
 155         }
 156         leaf reserved1 {
 157                 type uint16;
 158         }
 159         leaf request-transmission-policy {
 160                 type uint32;
 161                 description "
 162                         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.
 163                 ";
 164         }
 165         leaf maximum-sustained-traffic-rate {
 166                 type uint32;
 167                 description "
 168                         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.
 169
 170                 ";
 171         }
 172         leaf maximum-traffic-burst {
 173                 type uint32;
 174                 description "
 175                         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.
 176                 ";
 177         }
 178         leaf minimum-reserved-traffic-rate {
 179                 type uint16;
 180                 description
 181                         "
 182                         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.
 183
 184 ";
 185         }
 186         leaf assumed-minimum-reserved-traffic-rate-packet-size {
 187                 type uint16;
 188                 description
 189                 "
 190                         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.
 191
 192 ";
 193         }
 194         leaf maximum-concatenated-burst {
 195                 type uint16;
 196                 description
 197                 "
 198                         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.
 199 ";
 200         }
 201
 202         leaf upstream-peak-traffic-rate {
 203                 type uint32;
 204                 description
 205                 "
 206 Upstream Peak Traffic Rate is a 4-byte unsigned integer specifying the Peak traffic rate (in bits per second) which a
 207 Service Flow is allowed. This field is fully defined in section C.2.2.5.10.1 of [1].
 208                 ";
 209         }
 210
 211         leaf required-attribute-mask {
 212                 type uint32;
 213                 description
 214                 "
 215                         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.
 216
 217 ";
 218         }
 219         leaf forbidden-attribute-mask {
 220                 type uint32;
 221                 description
 222                 "
 223                         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.
 224 ";
 225         }
 226         leaf attribute-aggregation-rule-mask {
 227                 type uint32;
 228                 description
 229                 "
 230                         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.
 231 ";
 232         }
 233         leaf minimum-buffer {
 234                 type uint32;
 235                 description
 236                 "
 237 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.
 238                 ";
 239         }
 240         leaf target-buffer {
 241                 type uint32;
 242                 description
 243                 "
 244 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.
 245
 246                 ";
 247         }
 248         leaf maximum-buffer {
 249                 type uint32;
 250                 description
 251                 "
 252 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.
 253                 ";
 254         }
 255     }
 256
 257
 258     grouping ugs-envelope {
 259     leaf request-transmission-policy {
 260                 type uint32;
 261                 description "
 262                 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].
 263                 ";
 264     }
 265     leaf unsolicited-grant-size {
 266                 type uint16;
 267                 description "
 268                 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.
 269                 ";
 270     }
 271     leaf grants-interval {
 272                 type uint8;
 273                 description "
 274         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.
 275                 ";
 276     }
 277     leaf reserved {
 278                 type uint8;
 279                 description "
 280                 ";
 281     }
 282     leaf nominal-grant-interval {
 283                 type uint32;
 284                 description "
 285                         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].
 286
 287                 ";
 288     }
 289     leaf tolerated-grant-jitter {
 290                 type uint32;
 291                 description "
 292 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.
 293                 ";
 294     }
 295     leaf required-attribute-mask {
 296                 type uint32;
 297                 description "
 298 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.
 299                 ";
 300     }
 301     leaf forbidden-attribute-mask {
 302                 type uint32;
 303                 description "
 304 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.
 305                 ";
 306     }
 307     leaf attribute-aggregation-rule-mask {
 308                 type uint32;
 309                 description "
 310 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.
 311                 ";
 312     }
 313
 314     }
 315
 316
 317     grouping us-envelope {
 318     leaf traffic-priority {
 319                 type uint32;
 320                 description "
 321 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.
 322
 323                 ";
 324     }
 325     leaf downstream-resequencing {
 326                 type uint32;
 327                 description "
 328 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.
 329                 ";
 330     }
 331     leaf reserved0{
 332                 type uint32;
 333                 description "
 334
 335                 ";
 336     }
 337     leaf maximum-sustained-traffic-rate {
 338                 type uint32;
 339                 description "
 340 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.
 341
 342                 ";
 343     }
 344     leaf maximum-traffic-burst {
 345                 type uint32;
 346                 description "
 347 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.
 348
 349                 ";
 350     }
 351     leaf minimum-reserved-traffic-rate {
 352                 type uint32;
 353                 description "
 354 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.
 355
 356                 ";
 357     }
 358     leaf assumed-minimum-reserved-traffic-rate-packet-size {
 359                 type uint32;
 360                 description "
 361 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.
 362
 363
 364                 ";
 365     }
 366     leaf reserved1{
 367                 type uint32;
 368                 description "
 369
 370                 ";
 371     }
 372     leaf maximum-downstream-latency {
 373                 type uint32;
 374                 description "
 375 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.
 376
 377
 378                 ";
 379     }
 380     leaf downstream-peak-traffic-rate {
 381                 type uint32;
 382                 description "
 383 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.
 384
 385                 ";
 386     }
 387     leaf required-attribute-mask {
 388                 type uint32;
 389                 description "
 390 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.
 391
 392                 ";
 393     }
 394     leaf forbidden-attribute-mask {
 395                 type uint32;
 396                 description "
 397 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.
 398
 399                 ";
 400     }
 401     leaf attribute-aggregation-rule-mask {
 402                 type uint32;
 403                 description "
 404 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.
 405
 406                 ";
 407     }
 408     }
 409
 410
 411     container traffic-profile-flowspec {
 412         leaf traffic-profile-type {
 413                 type traffic-profile-type;
 414                 default flowspec;
 415                 description "This attribute contains the type of upstream flow scheduling type.";
 416         }
 417         container authorized-envelope {
 418                 uses flowspec-envelope;
 419                 description "manadatory";
 420         }
 421         container reserved-envelope {
 422                 uses flowspec-envelope;
 423                 description "optional";
 424         }
 425         container committed-envelope {
 426                 uses flowspec-envelope;
 427                 description "optional";
 428         }
 429     }
 430
 431
 432     container traffic-profile-docsis-service-class-name {
 433         leaf traffic-profile-type {
 434                 type traffic-profile-type;
 435                 default docsis-service-class-name;
 436                 description "This attribute contains the type of upstream flow scheduling type.";
 437         }
 438         leaf service-class-name {
 439                 type string;
 440                 description
 441                 "
 442                 xxx - length 2 to 128?
 443
 444                 The Service Class Name is MUST be 2-16 bytes of null-terminated ASCII string.
 445                 (Refer to section C.2.2.3.4 of [1]).  This name MUST be padded with null bytes
 446                 to align on a 4-byte boundary.
 447                 ";
 448         }
 449     }
 450
 451
 452     container traffic-profile-best-effort {
 453         leaf traffic-profile-type {
 454                 type traffic-profile-type;
 455                 default best-effort;
 456                 description "This attribute contains the type of upstream flow scheduling type.";
 457         }
 458         container authorized-envelope {
 459                 uses default-envelope;
 460                 description "manadatory";
 461         }
 462         container reserved-envelope {
 463                 uses default-envelope;
 464                 description "optional";
 465         }
 466         container committed-envelope {
 467                 uses default-envelope;
 468                 description "optional";
 469         }
 470     }
 471
 472     container traffic-profile-non-real-time-polling-service {
 473         leaf traffic-profile-type {
 474                 type traffic-profile-type;
 475                 default non-real-time-polling-service ;
 476                 description "This attribute contains the type of upstream flow scheduling type.";
 477         }
 478         container authorized-envelope {
 479                 uses default-envelope;
 480                 description "manadatory";
 481         }
 482         container reserved-envelope {
 483                 uses default-envelope;
 484                 description "optional";
 485         }
 486         container committed-envelope {
 487                 uses default-envelope;
 488                 description "optional";
 489         }
 490     }
 491
 492
 493     container traffic-profile-real-time-polling-service {
 494         leaf traffic-profile-type {
 495                 type traffic-profile-type;
 496                 default real-time-polling-service ;
 497                 description "This attribute contains the type of upstream flow scheduling type.";
 498         }
 499         container authorized-envelope {
 500                 uses default-envelope;
 501                 description "manadatory";
 502         }
 503         container reserved-envelope {
 504                 uses default-envelope;
 505                 description "optional";
 506         }
 507         container committed-envelope {
 508                 uses default-envelope;
 509                 description "optional";
 510         }
 511     }
 512
 513     container traffic-profile-unsolicited-grant-service {
 514         leaf traffic-profile-type {
 515                 type traffic-profile-type;
 516                 default  unsolicited-grant-service ;
 517                 description "This attribute contains the type of upstream flow scheduling type.";
 518         }
 519         container authorized-envelope {
 520                 uses ugs-envelope;
 521                 description "manadatory";
 522         }
 523         container reserved-envelope {
 524                 uses ugs-envelope;
 525                 description "optional";
 526         }
 527         container committed-envelope {
 528                 uses ugs-envelope;
 529                 description "optional";
 530         }
 531     }
 532
 533     container traffic-profile-unsolicited-grant-service-with-activity-detection {
 534         leaf traffic-profile-type {
 535                 type traffic-profile-type;
 536                 default  unsolicited-grant-service-with-activity-detection;
 537                 description "This attribute contains the type of upstream flow scheduling type.";
 538         }
 539         container authorized-envelope {
 540                 uses ugs-envelope;
 541                 description "manadatory";
 542         }
 543         container reserved-envelope {
 544                 uses ugs-envelope;
 545                 description "optional";
 546         }
 547         container committed-envelope {
 548                 uses ugs-envelope;
 549                 description "optional";
 550         }
 551     }
 552
 553     container traffic-profile-downstream-service {
 554         leaf traffic-profile-type {
 555                 type traffic-profile-type;
 556                 default  downstream-service ;
 557                 description "This attribute contains the type of upstream flow scheduling type.";
 558         }
 559         container authorized-envelope {
 560                 uses us-envelope;
 561                 description "manadatory";
 562         }
 563         container reserved-envelope {
 564                 uses us-envelope;
 565                 description "optional";
 566         }
 567         container committed-envelope {
 568                 uses us-envelope;
 569                 description "optional";
 570         }
 571
 572     }
 573
 574
 575     container traffic-profile-upstream-drop {
 576         leaf traffic-profile-type {
 577                 type traffic-profile-type;
 578                 default  upstream-drop;
 579                 description "This attribute contains the type of upstream flow scheduling type.";
 580         }
 581     }
 582
 583 }