organization "OpenDaylight Project";
contact "TBD";
+
description
"This module contains a collection of groupings and
data definition statements related to the configuration
of Traffic Profiles.";
- revision "2014-01-20" {
+ revision "2014-08-08" {
description "Initial revision of packetcable traffic profile";
}
type binary {
length "0..4";
}
- description
- "32-bit IEEE floating point number" ;
+ description
+ "32-bit IEEE floating point number" ;
}
typedef traffic-profile-type {
- description
- "
- 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.
+ description
+ "
+ 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.
- 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.
+ 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.
- 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.
+ 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.
- • Bit 0: Authorized Envelope
+ • Bit 0: Authorized Envelope
- • Bit 1: Reserved Envelope
+ • Bit 1: Reserved Envelope
- • Bit 2: Committed Envelope
+ • Bit 2: Committed Envelope
- 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.
+ 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.
- For the Traffic Profile formats that allow multiple sets of envelope parameters, the mapping of envelope parameter sets follows one of the following methods:
+ For the Traffic Profile formats that allow multiple sets of envelope parameters, the mapping of envelope parameter sets follows one of the following methods:
- • 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.
+ • 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.
- • 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.
+ • 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.
- 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.
+ 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.
";
type enumeration {
enum flowspec { value 0; }
enum docsis-service-class-name { value 1; }
- enum docsis-specific-paramterization { value 2; }
+ enum docsis-specific-parameterization { value 2; }
enum upstream-drop { value 3; }
enum best-effort { value 4; }
• RSpec Reserved Rate (R) ~= used to calculate the Polling Interval
• RSpec Slack Term ~= Tolerated Polling Jitter
+Token Bucket Rate [r] (encoded as IEEE floating point)
+0x461C4000 (10,000 Bps)
+Token Bucket Size [b] (encoded as IEEE floating point)
+0x43480000 (200 bytes)
+Peak Data Rate [p] (encoded as IEEE floating point)
+0x461C4000 (10,000 Bps)
+Minimum Policed Unit [m]
+0x000000C8 (200 bytes)
+Maximum Packet Size [M]
+0x000000C8 (200 bytes)
+Rate [R] (encoded as IEEE floating point)
+0x461C4000 (10,000 Bps)
+Slack Term [S]
+0x00000320 (800 μs)
";
- leaf token-bucket-rate {
- type float;
- description "[r] (IEEE floating point number ";
- }
- leaf token-bucket-size {
- type float;
- description "[p] IEEE floating point number";
- }
- leaf peak-data-rate {
- type float;
- description "[m] IEEE floating point number";
- }
- leaf minimum-policed-unit {
- type uint32;
- description "[m] (integer)";
- }
-
- leaf maximum-packet-size {
- type uint32;
- description "[M] (integer)";
- }
- leaf rate {
- type uint32;
- description "[R] (IEEE floating point number)";
- }
- leaf slack-term {
- type uint32;
- description "[S] (integer)";
- }
+ leaf token-bucket-rate {
+ type float;
+ description "[r] (IEEE floating point number
+
+ default 10000.0;
+ ";
+ }
+ leaf token-bucket-size {
+ type float;
+ description "[p] IEEE floating point number";
+ default 200;
+ }
+ leaf peak-data-rate {
+ type float;
+ description "[m] IEEE floating point number
+
+ default 10000.0;
+
+ ";
+ }
+ leaf minimum-policed-unit {
+ type uint32;
+ description "[m] (integer)";
+ default 200;
+ }
+
+ leaf maximum-packet-size {
+ type uint32;
+ description "[M] (integer)";
+ default 200;
+ }
+ leaf rate {
+ type uint32;
+ description "[R] (IEEE floating point number)";
+ default 10000;
+ }
+ leaf slack-term {
+ type uint32;
+ description "[S] (integer)";
+ default 800;
+ }
}
grouping default-envelope {
- leaf traffic-priority {
- type uint8;
- description
- "
- 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.
- ";
- }
- leaf reserved0 {
- type uint8;
- }
- leaf reserved1 {
- type uint16;
- }
- leaf request-transmission-policy {
- type uint32;
- description "
- 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.
- ";
- }
- leaf maximum-sustained-traffic-rate {
- type uint32;
- description "
- 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.
-
- ";
- }
- leaf maximum-traffic-burst {
- type uint32;
- description "
- 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.
- ";
- }
- leaf minimum-reserved-traffic-rate {
- type uint16;
- description
- "
- 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.
+ leaf traffic-priority {
+ type uint8;
+ description
+ "
+ 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.
+ ";
+ default 0;
+ }
+ leaf reserved0 {
+ type uint8;
+ default 0;
+ }
+ leaf reserved1 {
+ type uint16;
+ default 0;
+ }
+ leaf request-transmission-policy {
+ type uint32;
+ description "
+ 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.
+ ";
+ default 0;
+ }
+ leaf maximum-sustained-traffic-rate {
+ type uint32;
+ description "
+ 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.
+
+ ";
+ default 0;
+ }
+ leaf maximum-traffic-burst {
+ type uint32;
+ description "
+ 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.
+ ";
+ default 3044;
+ }
+ leaf minimum-reserved-traffic-rate {
+ type uint16;
+ description
+ "
+ 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.
";
- }
- leaf assumed-minimum-reserved-traffic-rate-packet-size {
- type uint16;
- description
- "
- 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.
-
+ default 0;
+ }
+ leaf assumed-minimum-reserved-traffic-rate-packet-size {
+ type uint16;
+ description
+ "
+ 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.
+
";
- }
- leaf maximum-concatenated-burst {
- type uint16;
- description
- "
- 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.
+ default 0;
+ }
+ leaf maximum-concatenated-burst {
+ type uint16;
+ description
+ "
+ 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.
";
- }
+ default 1522;
+ }
- leaf upstream-peak-traffic-rate {
- type uint32;
- description
- "
+ leaf upstream-peak-traffic-rate {
+ type uint32;
+ description
+ "
Upstream Peak Traffic Rate is a 4-byte unsigned integer specifying the Peak traffic rate (in bits per second) which a
Service Flow is allowed. This field is fully defined in section C.2.2.5.10.1 of [1].
- ";
- }
+ ";
+ default 0;
+ }
- leaf required-attribute-mask {
- type uint32;
- description
- "
- 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.
+ leaf required-attribute-mask {
+ type uint32;
+ description
+ "
+ 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.
";
- }
- leaf forbidden-attribute-mask {
- type uint32;
- description
- "
- 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.
+ default 0;
+ }
+ leaf forbidden-attribute-mask {
+ type uint32;
+ description
+ "
+ 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.
";
- }
- leaf attribute-aggregation-rule-mask {
- type uint32;
- description
- "
- 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.
+ default 0;
+ }
+ leaf attribute-aggregation-rule-mask {
+ type uint32;
+ description
+ "
+ 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.
";
- }
- leaf minimum-buffer {
- type uint32;
- description
- "
+ default 0;
+ }
+ leaf minimum-buffer {
+ type uint32;
+ description
+ "
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.
- ";
- }
- leaf target-buffer {
- type uint32;
- description
- "
+ ";
+ default 0;
+ }
+ leaf target-buffer {
+ type uint32;
+ description
+ "
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.
- ";
- }
- leaf maximum-buffer {
- type uint32;
- description
- "
+ ";
+ default 0;
+ }
+ leaf maximum-buffer {
+ type uint32;
+ description
+ "
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.
- ";
- }
+ ";
+ default 0;
+ }
}
grouping ugs-envelope {
leaf request-transmission-policy {
- type uint32;
- description "
- 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].
- ";
+ type uint32;
+ description "
+ 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].
+ ";
+ default 0;
}
leaf unsolicited-grant-size {
- type uint16;
- description "
- 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.
- ";
+ type uint16;
+ description "
+ 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.
+ ";
+ default 0;
}
leaf grants-interval {
- type uint8;
- description "
- 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.
- ";
+ type uint8;
+ description "
+ 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.
+ ";
+ default 1;
}
leaf reserved {
- type uint8;
- description "
- ";
+ type uint8;
+ description "
+ ";
+ default 0;
}
leaf nominal-grant-interval {
- type uint32;
- description "
- 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].
-
- ";
+ type uint32;
+ description "
+ 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].
+
+ ";
+ default 0;
}
leaf tolerated-grant-jitter {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf required-attribute-mask {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf forbidden-attribute-mask {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf attribute-aggregation-rule-mask {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
-
+
}
grouping us-envelope {
- leaf traffic-priority {
- type uint32;
- description "
+ leaf us-traffic-priority {
+ type uint8;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf downstream-resequencing {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf reserved0{
- type uint32;
- description "
+ type uint32;
+ description "
- ";
+ ";
+ default 0;
}
leaf maximum-sustained-traffic-rate {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf maximum-traffic-burst {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 3044;
}
leaf minimum-reserved-traffic-rate {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf assumed-minimum-reserved-traffic-rate-packet-size {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf reserved1{
- type uint32;
- description "
+ type uint32;
+ description "
- ";
+ ";
+ default 0;
}
leaf maximum-downstream-latency {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf downstream-peak-traffic-rate {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf required-attribute-mask {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf forbidden-attribute-mask {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
leaf attribute-aggregation-rule-mask {
- type uint32;
- description "
+ type uint32;
+ description "
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.
- ";
+ ";
+ default 0;
}
}
- container traffic-profile-flowspec {
- leaf traffic-profile-type {
- type traffic-profile-type;
- default flowspec;
- description "This attribute contains the type of upstream flow scheduling type.";
- }
- container authorized-envelope {
- uses flowspec-envelope;
- description "manadatory";
- }
- container reserved-envelope {
- uses flowspec-envelope;
+ grouping traffic-profile-flowspec {
+ container f-authorized-envelope {
+ uses flowspec-envelope;
+ description "mandatory";
+ }
+ container f-reserved-envelope {
+ uses flowspec-envelope;
description "optional";
- }
- container committed-envelope {
- uses flowspec-envelope;
+ }
+ container f-committed-envelope {
+ uses flowspec-envelope;
description "optional";
- }
+ }
}
- container traffic-profile-docsis-service-class-name {
- leaf traffic-profile-type {
- type traffic-profile-type;
- default docsis-service-class-name;
- description "This attribute contains the type of upstream flow scheduling type.";
- }
- leaf service-class-name {
- type string;
+ grouping traffic-profile-docsis-service-class-name {
+ leaf service-class-name {
+ type string;
description
- "
- xxx - length 2 to 128?
+ "
+ xxx - length 2 to 128?
- The Service Class Name is MUST be 2-16 bytes of null-terminated ASCII string.
- (Refer to section C.2.2.3.4 of [1]). This name MUST be padded with null bytes
- to align on a 4-byte boundary.
- ";
- }
+ The Service Class Name is MUST be 2-16 bytes of null-terminated ASCII string.
+ (Refer to section C.2.2.3.4 of [1]). This name MUST be padded with null bytes
+ to align on a 4-byte boundary.
+ ";
+ }
}
- container traffic-profile-best-effort {
- leaf traffic-profile-type {
- type traffic-profile-type;
- default best-effort;
- description "This attribute contains the type of upstream flow scheduling type.";
- }
- container authorized-envelope {
- uses default-envelope;
- description "manadatory";
- }
- container reserved-envelope {
- uses default-envelope;
+ grouping traffic-profile-best-effort {
+ container be-authorized-envelope {
+ uses default-envelope;
+ description "mandatory";
+ }
+ container bereserved-envelope {
+ uses default-envelope;
description "optional";
- }
- container committed-envelope {
- uses default-envelope;
+ }
+ container be-committed-envelope {
+ uses default-envelope;
description "optional";
- }
+ }
}
- container traffic-profile-non-real-time-polling-service {
- leaf traffic-profile-type {
- type traffic-profile-type;
- default non-real-time-polling-service ;
- description "This attribute contains the type of upstream flow scheduling type.";
- }
- container authorized-envelope {
- uses default-envelope;
- description "manadatory";
- }
- container reserved-envelope {
- uses default-envelope;
+ grouping traffic-profile-non-real-time-polling-service {
+ container nrtp-authorized-envelope {
+ uses default-envelope;
+ description "mandatory";
+ }
+ container nrtp-reserved-envelope {
+ uses default-envelope;
description "optional";
- }
- container committed-envelope {
- uses default-envelope;
+ }
+ container nrtp-committed-envelope {
+ uses default-envelope;
description "optional";
- }
+ }
}
- container traffic-profile-real-time-polling-service {
- leaf traffic-profile-type {
- type traffic-profile-type;
- default real-time-polling-service ;
- description "This attribute contains the type of upstream flow scheduling type.";
- }
- container authorized-envelope {
- uses default-envelope;
- description "manadatory";
- }
- container reserved-envelope {
- uses default-envelope;
+ grouping traffic-profile-real-time-polling-service {
+ container rtp-authorized-envelope {
+ uses default-envelope;
+ description "mandatory";
+ }
+ container rtp-reserved-envelope {
+ uses default-envelope;
description "optional";
- }
- container committed-envelope {
- uses default-envelope;
+ }
+ container rtp-committed-envelope {
+ uses default-envelope;
description "optional";
- }
+ }
}
- container traffic-profile-unsolicited-grant-service {
- leaf traffic-profile-type {
- type traffic-profile-type;
- default unsolicited-grant-service ;
- description "This attribute contains the type of upstream flow scheduling type.";
- }
- container authorized-envelope {
- uses ugs-envelope;
- description "manadatory";
- }
- container reserved-envelope {
- uses ugs-envelope;
+ grouping traffic-profile-unsolicited-grant-service {
+ container ugs-authorized-envelope {
+ uses ugs-envelope;
+ description "mandatory";
+ }
+ container ugs-reserved-envelope {
+ uses ugs-envelope;
description "optional";
- }
- container committed-envelope {
- uses ugs-envelope;
+ }
+ container ugs-committed-envelope {
+ uses ugs-envelope;
description "optional";
- }
+ }
}
- container traffic-profile-unsolicited-grant-service-with-activity-detection {
- leaf traffic-profile-type {
- type traffic-profile-type;
- default unsolicited-grant-service-with-activity-detection;
- description "This attribute contains the type of upstream flow scheduling type.";
- }
- container authorized-envelope {
- uses ugs-envelope;
- description "manadatory";
- }
- container reserved-envelope {
- uses ugs-envelope;
+ grouping traffic-profile-unsolicited-grant-service-with-activity-detection {
+ container usga-authorized-envelope {
+ uses ugs-envelope;
+ description "mandatory";
+ }
+ container usga-reserved-envelope {
+ uses ugs-envelope;
description "optional";
- }
- container committed-envelope {
- uses ugs-envelope;
+ }
+ container usga-committed-envelope {
+ uses ugs-envelope;
description "optional";
- }
+ }
}
- container traffic-profile-downstream-service {
- leaf traffic-profile-type {
- type traffic-profile-type;
- default downstream-service ;
- description "This attribute contains the type of upstream flow scheduling type.";
- }
- container authorized-envelope {
- uses us-envelope;
- description "manadatory";
- }
- container reserved-envelope {
- uses us-envelope;
+
+ grouping traffic-profile-downstream-service {
+ container ds-authorized-envelope {
+ uses us-envelope;
+ description "mandatory";
+ }
+ container ds-reserved-envelope {
+ uses us-envelope;
description "optional";
- }
- container committed-envelope {
- uses us-envelope;
+ }
+ container ds-committed-envelope {
+ uses us-envelope;
description "optional";
- }
+ }
+ }
+
+ grouping traffic-profile-upstream-drop {
+ }
+
+ grouping traffic-profile-docsis-specific-parameterization {
}
- container traffic-profile-upstream-drop {
- leaf traffic-profile-type {
+
+ grouping traffic-profile-grouping {
+ leaf tp-type {
type traffic-profile-type;
- default upstream-drop;
+ default best-effort;
description "This attribute contains the type of upstream flow scheduling type.";
}
- }
-
+ choice tp-type-choice {
+ case "flowspec" { uses traffic-profile-flowspec; }
+ case "docsis-service-class-name" { uses traffic-profile-docsis-service-class-name; }
+ case "docsis-specific-parameterization" { uses traffic-profile-docsis-specific-parameterization; }
+ case "upstream-drop" { uses traffic-profile-upstream-drop; }
+ case "best-effort" { uses traffic-profile-best-effort; }
+ case "unsolicited-grant-service" { uses traffic-profile-unsolicited-grant-service; }
+ case "unsolicited-grant-service-with-activity-detection" { uses traffic-profile-unsolicited-grant-service-with-activity-detection; }
+ case "non-real-time-polling-service" { uses traffic-profile-non-real-time-polling-service; }
+ case "real-time-polling-service" { uses traffic-profile-real-time-polling-service; }
+ case "downstream-service" { uses traffic-profile-downstream-service; }
+ }
+ }
+
+
+// grouping taffic-profile-default-singleton-grouping {
+// grouping flowspec { uses traffic-profile-flowspec; }
+// grouping docsis-service-class-name { uses traffic-profile-docsis-service-class-name; }
+// grouping docsis-specific-parameterization { uses traffic-profile-docsis-specific-parameterization; }
+// grouping upstream-drop { uses traffic-profile-upstream-drop; }
+// grouping best-effort { uses traffic-profile-best-effort; }
+// grouping unsolicited-grant-service { uses traffic-profile-unsolicited-grant-service; }
+// grouping unsolicited-grant-service-with-activity-detection { uses traffic-profile-unsolicited-grant-service-with-activity-detection; }
+// grouping non-real-time-polling-service { uses traffic-profile-non-real-time-polling-service; }
+// grouping real-time-polling-service { uses traffic-profile-real-time-polling-service; }
+// grouping downstream-service { uses traffic-profile-downstream-service; }
+// }
}
Code Review / packetcable.git / commitdiff