The port-based scheduler feature was introduced to allow HQoS bandwidth allocation based on available bandwidth at the egress port level. The port-based scheduler works at the egress line rate of the port to which it is attached. Port-based scheduling bandwidth allocation automatically includes the Inter-Frame Gap (IFG) and preamble for packets forwarded on queues servicing egress Ethernet ports. However, on PoS and SDH based ports, the HDLC encapsulation overhead and other framing overhead per packet is not known by the system. Instead of automatically determining the encapsulation overhead for SDH or SONET queues, the system provides a configurable frame encapsulation efficiency parameter that allows the user to select the average encapsulation efficiency for all packets forwarded out the egress queue.
To accommodate inactive queues, the system calculates a Minimum Information Rate (MIR) for each queue. To calculate each queue’s MIR, the system determines what that queue’s Fair Information Rate (FIR) would be if that queue had actually been active during the latest iteration of the virtual scheduling algorithm. For example, if three queues are active (1, 2, and 3) and two queues are inactive (4 and 5), the system first calculates the FIR for each active queue. Then it recalculates the FIR for queue 4 assuming queue 4 was active with queues 1, 2, and 3 and uses the result as the queue’s MIR. The same is done for queue 5 using queues 1, 2, 3, and 5. The MIR for each inactive queue is used as the operational PIR for each queue.
Service/Subscriber Egress Port Bandwidth Allocation
The port-based egress scheduler can be used to allocate bandwidth to each service or subscriber associated with the port. While egress queues on the service can have a child association with a scheduler policy on the SAP or multi-service site, all queues must vie for bandwidth from an egress port. Two methods are supported to allocate bandwidth to each service
or subscriber queue:
1.
|
Service or subscriber queue association with a scheduler on the SAP or multi-service site which is itself associated with a port-level scheduler.
|
2.
|
Service or subscriber queue association directly with a port-level scheduler.
|
Service or Subscriber Scheduler Child to Port Scheduler Parent
The service or subscriber scheduler to port scheduler association model allows for multiple services
or subscriber to have independent scheduler policy definitions while the independent schedulers receive bandwidth from the scheduler at the port level. By using two scheduler policies, available egress port bandwidth can be allocated fairly or unfairly depending on the desired behavior.
Figure 17 graphically demonstrates this model.

Due to the nature of the two scheduler policy, bandwidth is allocated on a per-service or per subscriber basis as opposed to a per-class basis. A common use of the two policy model is for a carrier-of-carriers mode of business. In essence, the goal of a carrier is to provide segments of bandwidth to providers who purchase that bandwidth as services. While the carrier does not concern itself with the interior services of the provider, it does however care how congestion affects the bandwidth allocation to each provider’s service. As an added benefit, the two policy approach provides the carrier with the ability to preferentially allocate bandwidth within a service
or subscriber context through the service
or subscriber level policy without affecting the overall bandwidth allocation to each service
or subscriber.
Figure 18 shows a per-service bandwidth allocation using the two scheduler policy model. While the figure shows services grouped by scheduling priority, it is expected that many service models will place the services in a common port priority and use weights to provide a weighted distribution between the service instances. Higher weights provide for relatively higher amounts of bandwidth.

The second model of bandwidth allocation on an egress access port is to directly associate a service or subscriber queue to a port-level scheduler. This model allows the port scheduler hierarchy to allocate bandwidth on a per class or priority basis to each service
or subscriber queue. This allows the provider to manage the available egress port bandwidth on a service tier basis ensuring that during egress port congestion, a deterministic behavior is possible from an aggregate perspective. While this provides an aggregate bandwidth allocation model, it does not inhibit per service or per subscriber queuing.
Figure 19 demonstrates the single, port scheduler policy model.
Figure 19 also demonstrates the optional aggregate rate limiter at the SAP, multi-service site
or subscriber level. The aggregate rate limiter is used to define a maximum aggregate bandwidth at which the child queues can operate. While the port-level scheduler is allocating bandwidth to each child queue, the current sum of the bandwidth for the service
or subscriber is monitored. Once the aggregate rate limit is reached, no more bandwidth is allocated to the children associated with the SAP, multi-service site,
or subscriber. Aggregate rate limiting is restricted to the single scheduler policy model and is mutually exclusive to defining SAP, multi-service site,
or subscriber scheduling policies.
The benefit of the single scheduler policy model is that the bandwidth is allocated per priority for all queues associated with the egress port. This allows a provider to preferentially allocate bandwidth to higher priority classes of service independent of service or subscriber instance. In many cases, a subscriber can purchase multiple services from a single site (VoIP, HSI, Video) and each service can have a higher premium value relative to other service types. If a subscriber has purchased a premium service class, that service class should get bandwidth before another subscriber’s best effort service class. When combined with the aggregate rate limit feature, the single port-level scheduler policy model provides a per-service instance or per-subscriber instance aggregate SLA and a class based port bandwidth allocation function.

A port-based bandwidth allocation mechanism must consider the effect that line encapsulation overhead plays relative to the bandwidth allocated per service or subscriber. The service
or subscriber level bandwidth definition (at the queue level) operates on a packet accounting basis. For Ethernet, this includes the DLC header, the payload and the trailing CRC. This does not include the IFG or the preamble. This means that an Ethernet packet will consume 20 bytes more bandwidth on the wire than what the queue accounted for. When considering HDLC encoded PoS or SDH ports, the overhead is variable based on ‘7e’ insertions (and other TDM framing issues). The HDLC and SONET/SDH frame overhead is not included for queues forwarding on PoS and SDH links.
From a provisioning perspective, queues and service level (and subscriber level) scheduler policies are always provisioned with packet-based parameters. The system will convert these values to frame-based on-the-wire values for the purpose of port bandwidth allocation. However, port-based scheduler policy scheduler maximum rates and CIR values are always interpreted as on-the-wire values and must be provisioned accordingly.
Figure 20 and
Figure 21 provide a logical view of bandwidth distribution from the port to the queue level and shows the packet or frame-based provisioning at each step.

A port-parent command in the sap-egress and network-queue QoS policy queue context defines the direct child/parent association between an egress queue and a port scheduler priority level. The
port-parent command is mutually exclusive to the already-existing
parent command, which associates a queue with a scheduler at the SAP, multi-service site
or subscriber profile level. It is possible to mix local parented (parent to service
or subscriber level scheduler) and port parented queues with schedulers on the same egress port.
The port-parent command only accepts a child/parent association to the eight priority levels on a port scheduler hierarchy. Similar to the local
parent command, two associations are supported, one for “within-cir” bandwidth (cir-level) and a second one for “above-cir” bandwidth (level). The “within-cir” association is optional and can be disabled by using the default “within-cir” weight value of 0. In the event that a queue with a defined parent port is on a port without a port scheduler policy applied, that queue will be considered an orphaned queue. If a queue with a parent command is defined on a port and the named scheduler is not found due a missing scheduler policy or a missing scheduler of that name, the queue will be considered orphaned as well.
A queue can be moved from a local (on the SAP, multi-service site, or subscriber profile) parent to a port parent priority level simply by executing the
port-parent command. Once the
port-parent command is executed, any local parent information for the queue is lost. The queue can also be moved back to a local parent at anytime by executing the local parent command. Lastly, the local parent or port parent association can be removed at any time by using the no version of the appropriate parent command.
Service or Subscriber-Level Scheduler Parental Association Scope
The port-parent command in the scheduler-policy scheduler context (at all tier levels) allows a scheduler to be associated with a port scheduler priority level. The
port-parent command is mutually exclusive to the
parent command for schedulers at tiers 2 and 3 within the scheduler policy. The
port-parent command is the only parent command allowed for schedulers in tier 1.
The port-parent command only accepts a child/parent association to the eight priority levels on a port scheduler hierarchy. Similar to the normal local parent command, two associations are supported, one for “within-cir” bandwidth (cir-level) and a second one for “above-cir” bandwidth (level). The “within-cir” association is optional and can be disabled by using the default “within-cir” weight value of 0. In the event that a scheduler with a port parent defined is on a port without a port scheduler policy applied, that scheduler will be considered an orphaned scheduler.
A scheduler in tiers 2 and 3 can be moved from a local (within the policy) parent to a port parent priority level simply by executing the port-parent command. Once the
port-parent command is executed, any local parent information for the scheduler is lost. The schedulers at tiers 2 and 3 can also be moved back to a local parent at anytime by executing the local parent command. Lastly, the local parent or port parent association can be removed at anytime by using the no version of the appropriate parent command. A scheduler in tier 1 can only be associated with a port parent and that port parent definition can be added or removed at anytime.

When a port scheduler is present on an egress port or channel, the system ensures that all queues and schedulers receive bandwidth from that scheduler to prevent free-running queues which can cause the aggregate operational PIR of the port or channel to oversubscribe the bandwidth available. When the aggregate maximum rate for the queues on a port or channel operate above the available line rate, the forwarding ratio between the queues will be affected by the hardware schedulers on the port and may not reflect the scheduling defined on the port or intermediate schedulers. Queues and schedulers that are either explicitly attached to the port scheduler using the port-parent command or are attached to an intermediate scheduler hierarchy that is ultimately attached to the port scheduler are managed through the normal eight priority levels. Queues and schedulers that are not attached directly to the port scheduler and are not attached to an intermediate scheduler that itself is attached to the port scheduler are considered orphaned queues and, by default, are tied to priority 1 with a weight of 0. All weight 0 queues and schedulers at priority level 1 are allocated bandwidth after all other children and each weight 0 child is given an equal share of the remaining bandwidth. This default orphan behavior may be overridden at the port scheduler policy by using the orphan-override command. The orphan-override command accepts the same parameters as the port-parent command. When the orphan-override command is executed, the parameters will be used as the port parent parameters for all orphans associated with a port using the port scheduler policy.
Another difference between the service level scheduler-policy and the port level port-scheduler-policy is in bandwidth allocation behavior. The port scheduler is designed to offer on-the-wire bandwidth. For Ethernet ports, this includes the IFG and the preamble for each frame and represents 20 bytes total per frame. The queues and intermediate service level schedulers (a service level scheduler is a scheduler instance at the SAP, multi-service site or subscriber profile level) operate based on packet overhead which does not include the IFG or preamble on Ethernet packets. In order for the port based virtual scheduling algorithm to function, it must convert the queue and service scheduler packet based required bandwidth and bandwidth limiters (CIR and rate PIR) to frame based values. This is accomplished by adding 20 bytes to each Ethernet frame offered at the queue level to calculate a frame based offered load. Then the algorithm calculates the ratio increase between the packet based offered load and the frame based offered load and uses this ratio to adapt the CIR and rate PIR values for the queue to frame-CIR and frame-PIR values. When a service level scheduler hierarchy is between the queues and the port based schedulers, the ratio between the average frame-offered-load and the average packet-offered-load is used to adapt the scheduler’s packet based CIR and rate PIR to frame based values. The frame based values are then used to distribute the port based bandwidth down to the queue level.
When all queues for a SAP, multi-service site or subscriber instance are attached directly to the port scheduler (using the port-parent command), it is possible to configure an agg-rate-limit for the queues. This is beneficial since the port scheduler does not provide a mechanism to enforce an aggregate SLA for a service
or subscriber and the agg-rate-limit provides this ability. Queues may be provisioned directly on the port scheduler when it is desirable to manage the congestion at the egress port based on class priority instead of on a per service object basis.
Since the sap-egress policy defines a queue’s parent association before the policy is associated with a service SAP or subscriber profile, it is possible for the policy to either not define a port-parent association or define an intermediate scheduler parenting that does not exist. As stated above, queues in this state are considered to be orphaned and automatically attached to port scheduler priority 1. Orphaned queues are included in the aggregate rate limiting behavior on the SAP
or subscriber instance they are created within.
Figure 23 illustrates the use of the vport on an Ethernet port of a Broadband Network Gateway (BNG). In this case, the vport represents a specific downstream DSLAM.
A vport cannot be parented to the port scheduler when it is using a port scheduler policy itself. It is thus important the user ensures that the sum of the max-rate parameter value in the port scheduler policies of all vport instances on a given egress Ethernet port does not oversubscribe the port’s rate. If it does, the scheduling behavior degenerates to that of the H/W scheduler on that port. A vport which uses an
agg-rate-limit can be parented to a port scheduler. This is explained in Section Applying Aggregate Rate Limit to a VPORT.
This model allows the user to over subscribe the Ethernet port. The application of the agg-rate-limit option is mutually exclusive with the application of a port scheduler policy to a vport.
When using this model, a subscriber host queue with the port-parent option enabled is scheduled within the context of the port’s port scheduler policy. More details are provided in the 7750 SR OS Triple Play Guide.
In essence, a group receives bandwidth from the port or from the vport and distributes it within the member levels of the group according to the weight of each level within the group. Each priority level will compete for bandwidth within the group based on its weight under congestion situation. If there is no congestion, a priority level can achieve up to its rate (cir-rate) worth of bandwidth.
•
|
Each QoS scheduler policy must have a unique policy ID.
|
•
|
Each QoS port scheduler policy must have a unique policy name.
|
Configuring and applying QoS policies is optional. If no QoS policy is explicitly applied to a SAP or IP interface, a default QoS policy is applied.
A:ALA-12>config>qos# info
#------------------------------------------
echo "QoS Policy Configuration"
#------------------------------------------
...
scheduler-policy "SLA1" create
description "NetworkControl(3), Voice(2) and NonVoice(1) have strict priorities"
tier 1
scheduler "All_traffic" create
description "All traffic goes to this scheduler eventually"
rate 11000
exit
exit
tier 2
scheduler "NetworkControl" create
description "network control traffic within the VPN"
parent All_traffic level 3 cir-level 3
rate 100
exit
scheduler "NonVoice" create
description "NonVoice of VPN and Internet traffic will be serviced by this scheduler"
parent All_traffic cir-level 1
rate 11000
exit
scheduler "Voice" create
description "Any voice traffic from VPN and Internet use this scheduler"
parent All_traffic level 2 cir-level 2
rate 5500
exit
exit
tier 3
scheduler "Internet_be" create
parent NonVoice cir-level 1
exit
scheduler "Internet_priority" create
parent NonVoice level 2 cir-level 2
exit
scheduler "Internet_voice" create
parent Voice
exit
scheduler "VPN_be" create
parent NonVoice cir-level 1
exit
scheduler "VPN_nc" create
parent NetworkControl
rate 100 cir 36
exit
scheduler "VPN_priority" create
parent NonVoice level 2 cir-level 2
exit
scheduler "VPN_reserved" create
parent NonVoice level 3 cir-level 3
exit
scheduler "VPN_video" create
parent NonVoice level 5 cir-level 5
rate 1500 cir 1500
exit
scheduler "VPN_voice" create
parent Voice
rate 2500 cir 2500
exit
exit
exit
sap-ingress 100 create
description "Used on VPN sap"
...
----------------------------------------------
A:ALA-12>config>qos#
CLI Syntax: config>customer
customer-id
qos sap-ingress-policy-id
A:SR>config>service# info
----------------------------------------------
epipe 6 customer 6 vpn 6 create
description "Distributed Epipe service to west coast"
sap 1/1/10:0 create
ingress
scheduler-policy "SLA2"
qos 100
exit
egress
scheduler-policy "SLA2"
qos 1010
exit
exit
...
----------------------------------------------
A:SR>config>service#
A:SR>config>service# info
----------------------------------------------
ies 88 customer 8 vpn 88 create
interface "Sector A" create
sap 1/1/1.2.2 create
ingress
scheduler-policy "SLA2"
qos 101
exit
egress
scheduler-policy "SLA2"
qos 1020
exit
exit
exit
no shutdown
exit
----------------------------------------------
A:SR>config>service#
A:SR>config>service# info
----------------------------------------------
...
vpls 700 customer 7 vpn 700 create
description "test"
stp
shutdown
exit
sap 1/1/9:0 create
ingress
scheduler-policy "SLA2"
qos 100
exit
egress
scheduler-policy "SLA2"
exit
exit
spoke-sdp 2:222 create
exit
mesh-sdp 2:700 create
exit
no shutdown
exit
...
----------------------------------------------
A:SR>config>service#
A:SR7>config>service# info
----------------------------------------------
...
vprn 1 customer 1 create
ecmp 8
autonomous-system 10000
route-distinguisher 10001:1
auto-bind ldp
vrf-target target:10001:1
interface "to-ce1" create
address 11.1.0.1/24
sap 1/1/10:1 create
ingress
scheduler-policy "SLA2"
exit
egress
scheduler-policy "SLA2"
exit
exit
exit
no shutdown
exit
epipe 6 customer 6 vpn 6 create
----------------------------------------------
A:SR7>config>service#
Configuring and applying QoS port scheduler policies is optional. If no QoS port scheduler policy is explicitly applied to a SAP or IP interface, a default QoS policy is applied.
Note that the create keyword is included in the command syntax upon creation of a policy.
level priority-level rate pir-rate [cir cir-rate]
*A:ALA-48>config>qos>port-sched-plcy# info
----------------------------------------------
description "Test Port Scheduler Policy"
orphan-override weight 50 cir-level 4 cir-weight 50
----------------------------------------------
*A:ALA-48>config>qos>port-sched-plcy#
The port-parent command defines a child/parent association between an egress queue and a port based scheduler or between an intermediate service scheduler and a port based scheduler. The command may be issued in three distinct contexts;
sap-egress>queue queue-id, and
network-queue> queue queue-id and
scheduler-policy>scheduler scheduler-name the
network-queue> queue queue-id context. The
port-parent command allows for a set of within-cir and above-cir parameters that define the port priority levels and weights for the queue or scheduler. If the port-parent command is executed without any parameters, the default parameters are assumed.
port-parent [level priority-level] [weight
priority-weight] [cir-level
cir-priority-level] [cir-weight
cir-priority-weight]
queue queue-id [{auto-expedite | best-effort | expedite}] [priority-mode | profile-mode] [create]
port-parent [level priority-level] [weight
priority-weight] [cir-level
cir-priority-level] [cir-weight
cir-priority-weight]
port-parent [level priority-level] [weight
priority-weight] [cir-level
cir-priority-level] [cir-weight
cir-priority-weight]
SR7>config>qos# no scheduler-policy SLA2
MINOR: QOS #1003 The policy has references
SR7>config>qos#
Example:
config>service>customer# multi-service-site “Test”
config>service>cust>multi-service-site# ingress
config>service>cust>multi-service-site>ingress# no
scheduler-policy
Example:
config>service# epipe 6
config>service>epipe# sap sap 1/1/9:0
config>service>epipe>sap# egress
config>service>epipe>sap>egress# no scheduler-policy
config>service>epipe>sap>egress# exit
config>service>epipe>sap# ingress
config>service>epipe>sap>ingress#
config>service>epipe>sap>ingress# no scheduler-policy
Example:
config>service# vprn 1
onfig>service>vprn# interface "to-ce1"
config>service>vprn>if# sap 1/1/10:1
config>service>vprn>if>sap# ingress
config>service>vprn>if>sap>ingress# no scheduler-policy
config>service>vprn>if>sap>ingress# exit
config>service>vprn>if>sap# egress
config>service>vprn>if>sap>egress# no scheduler-policy
config>service>vprn>if>sap>egress# exit
config>service>vprn>if>sap#
Example:
config>qos# no scheduler-policy SLA1
Example:
config>qos# no port-scheduler-policy test1
Example:
config>qos# copy scheduler-policy SLA1 SLA2
A:SR>config>qos#
...
#------------------------------------------
echo "QoS Policy Configuration"
#------------------------------------------
scheduler-policy "SLA1" create
description "NetworkControl(3), Voice(2) and NonVoice(1) have strict priorities"
tier 1
scheduler "All_traffic" create
description "All traffic goes to this scheduler eventually"
rate 11000
exit
exit
tier 2
scheduler "NetworkControl" create
description "network control traffic within the VPN"
parent "All_traffic" level 3 cir-level 3
rate 100
exit
scheduler "NonVoice" create
description "NonVoice of VPN and Internet traffic will be serviced by this scheduler"
parent "All_traffic" cir-level 1
rate 11000
exit
scheduler "Voice" create
description "Any voice traffic from VPN and Internet use this scheduler"
parent "All_traffic" level 2 cir-level 2
rate 5500
exit
exit
tier 3
scheduler "Internet_be" create
parent "NonVoice" cir-level 1
exit
scheduler "Internet_priority" create
parent "NonVoice" level 2 cir-level 2
exit
...
scheduler-policy "SLA2" create
description "NetworkControl(3), Voice(2) and NonVoice(1) have strict priorities"
tier 1
scheduler "All_traffic" create
description "All traffic goes to this scheduler eventually"
rate 11000
exit
exit
tier 2
scheduler "NetworkControl" create
description "network control traffic within the VPN"
parent "All_traffic" level 3 cir-level 3
rate 100
exit
scheduler "NonVoice" create
description "NonVoice of VPN and Internet traffic will be serviced by this scheduler"
parent "All_traffic" cir-level 1
rate 11000
exit
scheduler "Voice" create
description "Any voice traffic from VPN and Internet use this scheduler"
parent "All_traffic" level 2 cir-level 2
rate 5500
exit
exit
tier 3
scheduler "Internet_be" create
parent "NonVoice" cir-level 1
exit
scheduler "Internet_priority" create
parent "NonVoice" level 2 cir-level 2
exit
...
#------------------------------------------
A:SR>config>qos#