Software-Based Implementation
The subscriber aggregate rate is adjusted and based on an average frame size.
The user enables the use of this adjustment method by configuring the following option in the egress context of the subscriber profile:
CLI syntax:
config>subscr-mgmt>sub-profile>egress>encap-offset [type type]
This command allows the user to configure a default value to be used by all hosts of the subscriber in the absence of a valid signaled value. The following are configurable values:
pppoa-llc, pppoa-null, pppoeoa-llc, pppoeoa-llc-fcs, pppoeoa-llc-tagged, pppoeoa-llc-tagged-fcs, pppoeoa-null, pppoeoa-null-fcs, pppoeoa-null-tagged, pppoeoa-null-tagged-fcs, ipoa-llc, ipoa-null, ipoeoa-llc, ipoeoa-llc-fcs, ipoeoa-llc-tagged, ipoeoa-llc-tagged-fcs, ipoeoa-null, ipoeoa-null-fcs, ipoeoa-null-tagged, ipoeoa-null-tagged-fcs, pppoe, pppoe-tagged, ipoe, ipoe-tagged
Otherwise, the fixed packet offset is derived from the encapsulation type value signaled in the Access-loop-encapsulation sub-TLV in the Vendor-Specific PPPoE Tags as described in Section Signaling of Last Mile Encapsulation Type. Only signaling using PPPoE Tags is supported in the software based implementation. The last signaled valid value is then applied to all active hosts of this subscriber. If no value is signaled in the subscriber host session or the value in the fields of the Access-loop-encapsulation sub-TLV are invalid, then the offset applied to the aggregate rate of this subscriber uses the last valid value signaled by a host of this subscriber if it exists, or the user entered default type value if configured, or no offset is applied.
Configure the average frame size value to be used for this adjustment:
CLI syntax:
config>subscr-mgmt>sub-profile>egress>avg-frame-size bytes
The entered value must include the FCS but not the Inter-Frame Gap (IFG) or the preamble. If the user does not explicitly configure a value for the avg-frame-size parameter, then it is also assumed the offset is zero regardless of the signaled or user-configured value.
The computation of the subscriber aggregate rate consists of taking the average frame size, adding the encapsulation fixed offset including the AAL5 trailer, and then adding the variable offset consisting of the AAL5 padding to next multiple of 48 bytes. The AverageFrameExpansionRatio is then derived as follows:
AverageFrameExpansionRatio = (53/48 x (AverageFrameSize + FixedEncapOffset + AAL5Padding)) / (AverageFrameSize + IFG + Preamble).
When the last mile is Ethernet, the formula simplifies to:
AverageFrameExpansionRatio = (AverageFrameSize + FixedEncapOffset + IFG + Preamble) / (AverageFrameSize + IFG + Preamble).
The following are the frame size and rate applied to the subscriber queue and scheduler:
Subscriber Host Queue (no change):
Size = ImmediateEgressEncap + Data
Rate = ImmediateEgressEncap + Data
Subscriber Aggregate Rate Scheduler:
Size = ImmediateEgressEncap + Data
Rate = sub-agg-rate / AverageFrameExpansionRatio
Note that the CPM applies the AverageFrameExpansionRatio adjustment to the various components used in the determination of the net subscriber operational aggregate rate. It then pushes these adjusted components to IOM which then makes the calculation of the net subscriber operational aggregate rate.
The formula used by the IOM for this determination is:
sub-oper-agg-rate = min(sub-policy-agg-rate/AverageFrameExpansionRatio, ancp_rate/AverageFrameExpansionRatio) + (igmp_rate_delta/AverageFrameExpansionRatio),
where sub-policy-agg-rate is either the value configured in the agg-rate-limit parameter in the subscriber profile or the resulting RADIUS override value. In both cases, the CPM uses an internal override to download the adjusted value to IOM.
The value of sub-oper-agg-rate is stored in the IOM's subscriber table.
The following are the procedures for handling signaling changes or configuration changes affecting the subscriber profile:
If a new RADIUS update comes in for the aggregate subscriber rate, then a new subscriber aggregate ATM adjusted rate is computed by CPM using the last configured avg-frame-size and then programmed to IOM.
If the user changes the value of the avg-frame-size parameter, enables/disables the encap-offset option, or changes the parameter value of the encap-offset option, the CPM immediately triggers a re-evaluation of subscribers using the corresponding subscriber profile and an update the IOM with the new subscriber aggregate rate.
If the user changes the value of the agg-rate-limit parameter in a subscriber profile which has the avg-frame-size configured, this immediately triggers a re-evaluation of subscribers using the corresponding subscriber profile. An update to the subscriber aggregate rate is performed for those subscribers which rate has not been previously overridden by RADIUS.
If the user changes the type value of the encap-offset command, this immediately triggers a re-evaluation of subscribers using the corresponding subscriber profile. An update to the subscriber aggregate rate is performed for those subscribers which are currently using the default value.
If two hosts of the same subscriber signal two different encapsulation types, the last one signaled gets used at the next opportunity to re-evaluate the subscriber profile.
If a subscriber has a DHCP host, a static host or an ARP host, the subscriber aggregate rate continues to use the user-configured default encapsulation type value or the last valid encapsulation value signaled in the PPPoE tags by other hosts of the same subscriber. If none was signaled or configured, then no rate adjustment is applied.
Hardware-Based Implementation — The data path computes the adjusted frame size real-time for each serviced packet from a queue by adding the actual packet size to the fixed offset provided by CPM for this queue and variable AAL5 padding.
Like in the software based implementation, the user enables the use of the fixed offset and per packet variable expansion by configuring the following option in the egress context of the subscriber profile:
CLI syntax:
config>subscr-mgmt>sub-profile>egress>encap-offset [type type]
When this command is enabled, the fixed packet offset is derived from the encapsulation type value signaled in the Access-loop-encapsulation sub-TLV in the Vendor-Specific PPPoE Tags or DHCP Relay Options as described in Section Signaling of Last Mile Encapsulation Type.
If the user specifies an encapsulation type with the command, this value is used as the default value for all hosts of this subscriber until a host session signaled a valid value. The signaled value is applied to this host only and the remaining hosts of this subscriber continue to use the user entered default type value if configured, or no offset is applied. Hosts of the same subscriber using the same SLA profile and which are on the same SAP share the same instance of FC queues. In this case, the last valid encapsulation value signaled by a host of that same instance of the SAP egress QoS policy overrides any previous signaled or configured value.
The procedures for handling signaling changes or configuration changes affecting the subscriber profile are the same as in the software-based implementation with except for the following:
The avg-frame-size parameter in the subscriber profile is ignored.
If the user specifies an encapsulation type with the command, this value is used as the default value for all hosts of this subscriber until a host session signaled a valid value. The signaled value is applied to this host and other hosts of the same subscriber sharing the same SLA profile and which are on the same SAP. The remaining hosts of this subscriber continue to use the user entered default type value if configured, or no offset is applied.
If the user enables/disables the encap-offset option, or changes the parameter value of the encap-offset option, the CPM immediately triggers a re-evaluation of subscriber hosts using the corresponding subscriber profile and an update the IOM with the new fixed offset value.
If subscriber host session signals an encapsulation type at the session establishment time and subsequently sends a DHCP renewal message using a Layer 2 DHCP relay which does not insert option82 in a unicast message, the encapsulation type for this host does not change. TR-101 states that option82 is mandatory for DHCP broadcast messages).
If a subscriber has a static host or an ARP host, the subscriber host continues to use the user-configured default encapsulation type value or the last valid encapsulation value signaled in the PPPoE tags or DHCP relay options by other hosts of the same subscriber which use the same SLA profile instance. If none was signaled or configured, then no rate adjustment is applied.
The encapsulation type value signaled in DHCP relay options or PPPoE tags are not cross-checked against the host type. Thus, a host signaling PPPoA/LLC encapsulation type through DHCP relay options are not handled as if the packet included a PPPoE header when forwarded over the local Ethernet port. This results in applying an encap-offset in the data path which assumes the PPPoE header is added to forwarded packets over the local Ethernet port.
The encap-offset option forces all the rates to be either last-mile frame over the wire or local port frame over the wire, described as LM-FoW and FoW respectively. The system maintains a running average frame expansion ratio for each queue to convert queue rates between these two formats as described in Frame size, rates, and running average frame expansion ratio. The following are details of the queue and scheduler operation:
When the encap-offset option is configured in the subscriber profile, the subscriber host queue rates, that is, CLI and operational PIR and CIR as well as queue bucket updates, the queue statistics, that is, forwarded, dropped, and HQoS offered counters use the LM-FoW format. The scheduler policy CLI and operational rates also use LM-FoW format. The port scheduler max-rate and the priority level rates and weights, if a Weighted Scheduler Group is used, are always entered in CLI and interpreted as FoW rates. The same is true for an agg-rate-limit applied to a Vport. Finally the subscriber agg-rate-limit is entered in CLI as LM-FoW rate. When converting between LM-FoW and FoW rates, the queue running average frame expansion ratio value is used.
If the user enabled frame-based-accounting in a scheduler policy or queue-frame-based-accounting with subscriber agg-rate-limit and a port scheduler policy, the queue operational rate is capped to a user configured FoW rate. The scheduler policy operational rates are also in the FoW format. A user-configured queue avg-frame-overhead value is ignored because the running average frame expansion ratio is what is used when the encap-offset option is enabled.
If the user configured queue packet-byte-offset value, it is ignored and is not accounted for in the net packet offset calculation.
When no encap-offset is configured in the subscriber profile, that is, default and pre-R9.0 behavior, queue CLI and operational PIR and CIR rates, as well as queue bucket updates, the queue statistics, use data format. The scheduler policy CLI and operational rates also use data format. The port scheduler max-rate and the priority level rates and weights, if a Weighted Scheduler Group is used, and the subscriber agg-rate-limit are entered in CLI and interpreted as FoW rates. When converting between FoW and data rates, the queue avg-frame-overhead value is used and because this an Ethernet port, it is not user-configurable but constant and is equal to +20 bytes (IFG and preamble).
If the user enabled frame-based-accounting in a scheduler policy or queue-frame-based-accounting with subscriber agg-rate-limit and a port scheduler policy, the queue operational rate is capped to a user configured FoW rate in CLI which is then converted into a data rate using the queue avg-frame-overhead constant value of +20 bytes. The scheduler policy operational rates are in the FoW format.
If the user configured queue packet-byte-offset value, it adjusts the immediate packet size. This means that the queue rates, that is, operational PIR and CIR, and queue bucket updates use the adjusted packet size. In addition, the queue statistics are also reflected the adjusted packet size. Scheduler policy rates, which are data rates, use the adjusted packet size. The port scheduler max-rate and the priority level rates and weights, if a Weighted Scheduler Group is used, as well as the subscriber agg-rate-limit are always FoW rates and uses the actual frame size. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured, therefore, the offsets are applied to the statistics.