Configuration overview
This document uses the term ‟preprovisioning” in the context of preparing or preconfiguring entities such as chassis slots, cards, Media Dependent Adapters (MDAs), ports, and interfaces, before initialization. These entities can be installed while remaining administratively disabled (shutdown). When the entity is in a no shutdown state (administratively enabled), then the entity is considered to be provisioned.
For consistency across platforms, XRS Media Adapters (XMAs) and Compact XMAs (C‑XMAs) are modeled as MDAs.
Unless specified otherwise:
The term ‟card” is used generically to refer to both Input Output Modules (IOMs) and XCMs.
The term ‟MDA” is used generically to refer to both MDAs and XMAs.
Nokia routers provide the capability to configure chassis slots to accept specific card and MDA types and set the relevant configurations before the equipment is actually installed. The preprovisioning capability allows you to plan your configurations as well as monitor and manage your router hardware inventory. Ports and interfaces can also be preprovisioned. When the functionality is needed, the cards can be inserted into the appropriate chassis slots when required.
Chassis slots and card slots
Depending on the chassis type, the relationship between the chassis slot and card slot varies. Chassis slots represent the physical slots in the chassis where modules can be installed. Card slots represent the reference used in management interfaces when provisioning the modules and then using resources of those modules (for example, port references). See the appropriate platform Installation Guide for more information.
To preprovision a card slot, the card type must be specified. Users can enter card type information for each slot. When a card is installed in a slot and enabled, the system verifies that the installed card type matches the provisioned card type. If the parameters do not match, the card remains offline. A preprovisioned slot can remain empty without conflicting with populated slots.
The general syntax for the configuration of card slots is similar for all platforms, though the number of available slots varies by platform and chassis model. The supported card-types vary by chassis. See the appropriate platform Installation Guide for more information.
The 7950 XRS platforms accept XCMs in card slots. An XCM has two slots, each of which accept an XMA or C-XMA module. The C-XMA modules require a mechanical adapter to fit in an XMA slot.
In the config context, use the following CLI commands and syntax examples to provision the chassis slot and XCM:
A:XRS20>config# card 1
A:XRS20>config>card# card-type xcm-x20
The 7750 SR-2s/7s/14s platforms accept XCMs in card slots. The XCMs of the 7750 SR-2s/7s platforms have a single slot for an XMA or an XIOM module. The XCM of the 7750-14s have two slots for the XMA or XIOM modules.
The 7750 SR-1s platform supports a single XCM in a dedicated card slot. This XCM has a single XMA module. The type of XMA module is fixed based on the variant of 7750 SR-1s chassis. Both the XCM and the XMA must be provisioned.
The 7450 ESS-7/12, and 7750 SR-7/12, and 7750 SR-12e platforms accept either IMMs or IOMs in card slots. IOMs have two slots for pluggable MDAs. The IOM4-e and IOM4-e-B support MDA-e modules. The IOM5-e supports MDA-e-XP modules.
In the config context, use the following CLI commands and syntax examples to provision a card slot with an IOM:
A:SR12-1>config# card 1
A:SR12-1>config>card# card-type iom3
IMMs have integrated MDAs. The provisioning requirements depends on the generation of IMM that you use. See the IMM Installation Guide for more information.
The 7750 SR-a platforms support IOM-a cards in dedicated chassis slots. The 7750 SR-a4 supports one physical IOM-a in slot 3. This IOM-a is represented in the CLI as card 1. The 7750 SR-a8 supports two physical IOM-a cards, one in slot 3, the other in slot 6. These IOM-a cards are represented in the CLI as card 1 and card 2 respectively. The IOM-a does not have pluggable MDA slots. Each IOM-a can be configured to support up to four MDA-a or MDA-aXP modules. IOM-a cards are configured in the same manner as IOMs.
The 7750 SR-e platforms support the IOM-e modules in dedicated slots in the rear of each chassis. The 7750 SR-1e supports one physical IOM-e module. This IOM-e is represented in the CLI as card 1. The 7750 SR-2e supports two physical IOM-e cards. These IOM-e cards are represented in the CLI as card 1 and card 2 respectively. The 7750 SR-3e supports three physical IOM-e cards. These IOM-e cards are represented in the CLI as card 1, card 2, and card 3 respectively. The IOM-e does not have pluggable MDA slots. An IOM-e can be configured to support up to four MDA-e modules. IOM-e cards are configured in the same manner as IOMs.
XIOM modules
XIOM modules are modules that are used in 7750 SR-1s/2s/7s/14s platforms. These can be installed into an XCM instead of installing an XMA module. The XIOMs have two slots that support MDA-s modules (see MDA-a, MDA-aXP, MDA, MDA-e, and MDA-s modules).
The use of an XIOM introduces an additional index into the reference hierarchy. For example, a 7750 SR-14s with an XCM in card slot 1 can have an XMA in the first slot and an XIOM in the second slot. A possible configuration is shown in the following example:
#--------------------------------------------------
echo "Card Configuration"
#--------------------------------------------------
card 1
card-type xcm-14s
mda 1
mda-type s36-100gb-qsfp28 level cr1600g
no shutdown
exit
xiom x2
xiom-type iom-s-3.0t level cr1600g+
mda 1
mda-type ms2-400g-qsfpdd+2-100g-qsfp28
no shutdown
exit
mda 2
mda-type ms16-100g-sfpdd+4-100g-qsfp28
no shutdown
exit
no shutdown
exit
no shutdown
exit
On the 7750 SR-1s/2s/7s/14s, the MDA-s modules are supported when an XIOM is installed into a slot within an XCM. Up to two MDA-s can be installed in an XIOM. MDA-s names in CLI start with the letters "ms" (for example, ms16-100g-sfpdd+4-100g-qsfp28).
MDA-a, MDA-aXP, MDA, MDA-e, and MDA-s modules
MDAs are pluggable adapter cards that provide physical interface connectivity. MDAs are available in a variety of interface and density configurations. MDA modules differ by chassis. See the individual chassis guide and the individual MDA installation guides for more information about specific MDAs.
On the 7450 ESS-7/12, 7750 SR-7/12, and 7750 SR-12e, MDAs plug into IOMs. (MDA-e modules plug into the IOM4-e and IOM4-e-B, MDA-e-XP modules plug into the IOM5-e). Up to two MDAs can be provisioned on an IOM.
IMMs are designed with fixed integrated media cards, which may require provisioning, depending on the generation of the IMM.
MDA-a and MDA-aXP modules are used in the 7750 SR-a and the MDA-e and ISA2 modules are used in the 7750 SR-e chassis. Up to four MDAs can be provisioned for each IOM.
In all cases, the card slot and IOM or IMM card-type must be provisioned before an MDA can be provisioned. A preprovisioned MDA slot can remain empty without interfering with services on populated equipment. When an MDA is installed and enabled, the system verifies that the MDA type matches the provisioned type. If the parameters do not match, the MDA remains offline.
On the 7450 ESS-7/12, 7750 SR-7/12, and 7750 SR-12e platforms, MDA names in the CLI start with the letter 'm' (for example, m10-1gb-xp-sfp).
The following example displays the card, card-type, mda, and mda-type command usage in the 7750 SR-12:
*A:Dut-B# configure card 6
*A:Dut-B>config>card# card-type "iom4-e"
*A:Dut-B>config>card# mda 1
*A:Dut-B>config>card>mda# mda-type me1-100gb-cfp2
*A:Dut-B>config>card>mda# no shutdown
*A:Dut-B>config>card>mda# exit
*A:Dut-B>config>card# mda 2
*A:Dut-B>config>card>mda# mda-type "me10-10gb-sfp+"
*A:Dut-B>config>card>mda# no shutdown
*A:Dut-B>config>card>mda# exit
*A:Dut-B>config>card# no shutdown
The following example displays the configuration:
*A:Dut-B# admin display-config
echo "Card Configuration"
#--------------------------------------------------
card 6
card-type iom4-e
mda 1
mda-type me1-100gb-cfp2
no shutdown
exit
mda 2
mda-type me10-10gb-sfp+
no shutdown
exit
no shutdown
exit
#--------------------------------------------------
The 7750 SR-a4 and 7750 SR-a8 support only MDA-a and MDA-aXP modules, which are identified in the CLI with an ‟ma” prefix (for example, ma4-10gb-sfp+), or ‟max” prefix (for example, maxp10-10gb-sfp+). Likewise, the 7750 SR-1e, 7750 SR-2e, and 7750 SR-3e support only MDA-e modules, which are identified in the CLI with an ‟me” prefix, such as me1-100gb-cfp2.
The following example shows the card, card-type, mda, and mda-type command usage in the 7750 SR-1e:
Classic CLI commands
A:SR1e>config# card 1
A:SR1e>config>card# card-type iom-e
A:SR1e>config>card# mda 1
A:SR1e>config>card>mda# mda-type me10-10gb-sfp+
A:SR1e>config>card>mda# exit
A:SR1e>config>card# mda 4
A:SR1e>config>card>mda# mda-type me1-100gb-cfp2
A:SR1e>config>card>mda# exit
The following example displays the configuration for the 7750 SR-1e:
Classic CLI configuration
A:SR1e# admin display-config
. . .
----------------------------------------------
echo "Card Configuration"
#---------------------------------------------
card 1
card-type iom-e
mda 1
mda-type me10-10gb-sfp+
exit
mda 4
mda-type me1-100gb-cfp2
exit
exit
----------------------------------------------
A:SR1e#
The following example shows the card, card-type, mda, and mda-type command usage in the 7750 SR-3e:
MD-CLI commands
(gl)[/]
A:admin@Dut-J# configure card 1
(gl)[/configure card 1]
A:admin@Dut-J# card-type iom-e
*(gl)[/configure card 1]
A:admin@Dut-J# mda 1 mda-type isa2-aa
*(gl)[/configure card 1]
A:admin@Dut-J# mda 2 mda-type me10-10gb-sfp+
*(gl)[/configure card 1]
A:admin@Dut-J# mda 3 mda-type me2-100gb-qsfp28
*(gl)[/configure card 1]
A:admin@Dut-J# mda 4 mda-type me40-1gb-csfp
The following example displays the configuration for the 7750 SR-3e:
MD-CLI configuration
*(gl)[/configure card 1]
A:admin@Dut-J# info
card-type iom-e
mda 1 {
mda-type isa2-aa
}
mda 2 {
mda-type me10-10gb-sfp+
}
mda 3 {
mda-type me2-100gb-qsfp28
}
mda 4 {
mda-type me40-1gb-csfp
}
fp 1 {
}
XMAs/C-XMAs
XMAs are supported on the 7750 SR-1s/2s/7s/14s and 7950 XRS platforms. XMAs plug into XCMs. XCMs must be provisioned before an XMA can be provisioned with a type.
The XMA information must be configured before ports can be configured. After you configure the XCM, use the following CLI commands to provision XMAs.
A maximum of two XMAs can be configured on an XCM. The following example displays the card slot, card type, MDA slot, and MDA type command usage:
A:XRS20>config# card 1
A:XRS20>config>card# card-type xcm-x20
A:XRS20>config>card# mda 1
A:XRS20>config>card>mda# mda-type cx2-100g-cfp
A:XRS20>config>card>mda# power-priority-level 130
A:XRS20>config>card>mda# exit
A:XRS20>config>card# mda 2
A:XRS20>config>card>mda# mda-type cx20-10g-sfp
A:XRS20>config>card>mda# power-priority-level 135
A:XRS20>config>card>mda# exit
The following example displays the configuration:
A:XRS20# admin display-config
. . .
----------------------------------------------
echo "Card Configuration "
#------------------------------------------
card 1
card-type xcm-x20
mda 1
mda-type cx2-100g-cfp
power-priority-level 130
exit
mda 2
mda-type cx20-10g-sfp
power-priority-level 135
exit
exit
----------------------------------------------
A:XRS20#
On the 7950 XRS, the show card state output displays an ‟x” in the name of the XMA and ‟cx” in the name of a C-XMA:
A:Dut-A# show card state
===============================================================================
Card State
===============================================================================
Slot/ Provisioned Type Admin Operational Num Num Comments
Id Equipped Type (if different) State State Ports MDA
-------------------------------------------------------------------------------
1 xcm-x20 up up 2
1/1 cx20-10g-sfp up up 20
1/2 cx20-10g-sfp up up 20
2 xcm-x20 up up 2
2/1 cx20-10g-sfp up up 20
A cpm-x20 up up Active
B cpm-x20 up up Standby
===============================================================================
Hardware licensing
With the introduction of pay-as-you-grow licensing, level-based hardware assemblies (for example, FP4 and FP5 IOMs and XMAs) now include variants with license levels. These levels define the capacity and functionality of the assembly. The capacity controls aspects such as the number and types of connectors and breakout options that can be configured, as well as the total connector bandwidth. Licensing also controls the number of user (based on configuration) hardware egress queues and egress policers that are available per forwarding plane. For a more complete description of the levels available for a particular assembly, see the associated installation guide.
The license level must be provisioned for the assembly at the same time as the card type or MDA type is provisioned. Each assembly has a set of levels applicable to that particular IOM or XMA that are defined using mnemonic strings. For example, an assembly may have a level 'cr1200g' which refers to a functional level of 'core routing' and a capacity maximum bandwidth of 1.2 Tb/s. A second example of a license level is 'he2400g+', which refers to a functional level of 'high scale edge routing' and a capacity level of a bandwidth of 2.4 Tb/s but with Intelligent Fan In/Out to a higher bandwidth.
When an assembly is installed in the chassis, the license level encoded into the equipped assembly must match the value provisioned for the assembly. If they do not match, the assembly cannot become active in the chassis. The only exception is that a variant of the assembly with the maximum functional and capacity level is allowed to come up in a slot provisioned as any level; the restrictions in effect are at the provisioned level, but this allows this specific assembly to be used to replace any other level of that assembly if necessary.
The following example shows the provisioning of an XCM with two XMAs. The first XMA is a two complex, 2.4T 24-connector QSFP28 XMA with a license level of er2400g (edge routing, 2.4 Tb/s) and the second XMA is a two complex, 2.4T 6-connector CFP8 XMA with a license level of he1600g (high scale edge routing, 4 connector 1.2Tbps):
*A:bkvm20# configure card 4 card-type "xcm2-x20"
*A:bkvm20# configure card 4 mda 1 mda-type "x24-100g-qsfp28" level "er2400g"
*A:bkvm20# configure card 4 mda 2 mda-type "x6-400g-cfp8" level "he1600g"
*A:bkvm20# show mda
===============================================================================
MDA Summary
===============================================================================
Slot Mda Provisioned Type Admin Operational
Equipped Type (if different) State State
-------------------------------------------------------------------------------
4 1 x24-100g-qsfp28:er2400g up up
2 x6-400g-cfp8:he1600g up up
===============================================================================
The show card and show mda output display both the type and level of the assembly and indicates when there is a difference between the provisioned and installed levels. In the following example, the first XMA has a provisioned value matching the installed assembly and the second XMA has a difference in the provisioned and installed assembly.
*A:bkvm20# show mda 4/1 detail
===============================================================================
MDA 4/1 detail
===============================================================================
Slot Mda Provisioned Type Admin Operational
Equipped Type (if different) State State
-------------------------------------------------------------------------------
4 1 x24-100g-qsfp28:er2400g up up
MDA Licensing Data
Licensed Level : er2400g
Description : 2.4T, 24c, Edge Routing
*A:bkvm20# show mda 4/2 detail
===============================================================================
MDA 4/2 detail
===============================================================================
Slot Mda Provisioned Type Admin Operational
Equipped Type (if different) State State
-------------------------------------------------------------------------------
4 2 x6-400g-cfp8:he2400g up provisioned
x6-400g-cfp8:he1600g
MDA Licensing Data
Licensed Level : he1600g
Description : 1.6T, 4c, High Scale Edge Routing
The connector and bandwidth constraints of a card or MDA are viewed using the show licensing command.
*A:bkvm18>config>card>mda# show licensing 1/1
===============================================================================
Connector MAC Licensed Restrictions
-------------------------------------------------------------------------------
1/1/c1 1 Yes None
1/1/c2 1 Yes None
1/1/c3 1 Yes None
1/1/c4 1 Yes None
1/1/c5 1 No No Breakout Allowed
1/1/c6 1 No No Breakout Allowed
1/1/c7 2 Yes None
1/1/c8 2 Yes None
1/1/c9 2 Yes None
1/1/c10 2 Yes None
1/1/c11 2 No No Breakout Allowed
1/1/c12 2 No No Breakout Allowed
1/1/c13 3 Yes None
...
The number of hardware egress user queues and egress user policers (total, allocated, and free), that are dependent on the operational license level of the card, XIOM or MDA containing the FP, are displayed using the tools dump resource-usage card fp command.
*A:PE# tools dump resource-usage card 1 fp 1
===============================================================================
Resource Usage Information for Card Slot #1 FP #1
===============================================================================
Total Allocated Free
-------------------------------------------------------------------------------
...
Egress User Queues | 131072 384 130688
Egress User Policers | 393215 0 393215
...
===============================================================================
The tools dump resource-usage card fp command also displays the number of hardware egress queues available on the related FP that is dependent on the configured allocation of the percentage of ingress queues.
Software license activation
The pay-as-you-grow licensing of the 7750 SR hardware platforms includes the ability to distribute software based licenses to operational systems in a live network. This is done by the creation of a license key file containing various individual licenses, making this file available to a system, and then activating that license key file on the system. Nokia provides the Configuration License Manager (CLM) tool to assist in this process. Normally, the CLM would perform all the steps in license distribution to a target system and only the assignment of individual licenses within a system itself need to be managed using the management mechanism for the system itself.
The license key file is a secure distribution mechanism for the licenses. Within the license key file, are one or more license keys. Each license key is assigned for a particular target system identified using a UUID. This UUID is tied to the chassis of the system and therefore the license key can only be validated on the system with that chassis. Each license key is also tied to a specific major software release of SR OS.
When a license key file is available to a target system and is activated it is first validated to ensure it is applicable for the specified target. For the license key of the SR OS hardware platform to be valid, the operator must ensure that the:
license is for a 7xxx platform
UUID of the system matches the one encoded in the "UUID-locked" license key
SR OS software version (the major release number) matches the one encoded in the license key
license file is not expired
Validation or activation of the license key file results in zero or one license key that is valid for the running software on the target. If there is a valid license key, the records contained in that key are read and made available to the system (see Software license records).
There may be additional license keys in the file that are for the target system but for a different software release. This is the case when an upgrade of the system is planned. Those license keys shall be considered available however, the feature licenses contained within them are not available for use. These can be seen using the show system license available-licenses command.
A:bkvm20# show system license available-licenses
===============================================================================
Available Licenses
License name : sr-regress@list.nokia.com
License uuid : ab516e50-2413-44aa-9f7c-34b4e5b64d19
Machine uuid : ab516e50-2413-44aa-9f7c-34b4e5b64d19
License desc : 7xxx Platform
License prod : 7xxx Platform
License sros : TiMOS-[BC]-16.0.*
Current date : FRI NOV 03 15:53:54 UTC 2017
Issue date : FRI SEP 22 20:55:14 UTC 2017
Start date : FRI SEP 15 00:00:00 UTC 2017
End date : THU MAR 15 00:00:00 UTC 2018
-------------------------------------------------------------------------------
License name : sr-regress@list.nokia.com
License uuid : ab516e50-2413-44aa-9f7c-34b4e5b64d19
Machine uuid : ab516e50-2413-44aa-9f7c-34b4e5b64d19
License desc : 7xxx Platform
License prod : 7xxx Platform
License sros : TiMOS-[BC]-17.0.*
Current date : FRI NOV 03 15:53:54 UTC 2017
Issue date : FRI SEP 22 20:55:14 UTC 2017
Start date : FRI SEP 15 00:00:00 UTC 2017
End date : THU MAR 15 00:00:00 UTC 2018
-------------------------------------------------------------------------------
2 license(s) available.
===============================================================================
On a system boot, the license key file pointed to by the BOF is activated. If new license key files are activated on a system, the BOF should be updated to point to the new license key file. If there are active licenses in system that are in use and the node reboots and the license key file pointed to by the BOF either fails to validate or does not contain the in-use license records, the system is considered to be in unlicensed state. In this state, the node reboots every 60 minutes until the records are no longer in-use or a valid license key is provided that includes all the in use license records.
Software license records
The activate license key shall unlock a set of license records for use within the system. In Release 16.0, only Hardware Upgrade license records are distributed in the license keys. These can be used to upgrade the hardware capacity or the hardware functional level of a card or an XMA. These upgrades define a starting level and an upgraded level for the target assembly. Multiple instances of the same upgrade can be assigned to a system in the license key. The list of these records and the number in-use and available can be checked with the show licensing-entitlements command.
*A:bkvm20# show licensing entitlements
========================================================================
License Available In-Use State
------------------------------------------------------------------------
MDA Upgrades
cr1200g-cr1600g 1 1 VALID
cr1200g-er1200g 1 0 VALID
cr1600g-cr2400g 1 0 VALID
cr1600g-er1600g 2 0 VALID
cr2400g-er2400g 1 0 VALID
er1200g-er1600g 4 2 VALID
er1200g-he1200g 1 0 VALID
er1600g-er2400g 1 0 VALID
er1600g-he1600g 1 0 VALID
er2400g-he2400g 1 0 VALID
he1200g-he1600g 1 0 VALID
he1600g-he2400g 1 0 VALID
========================================================================
*
An upgrade can be assigned to a particular card or XMA using the upgrade command within the card or mda context. Multiple upgrades can be assigned to the same card or XMA if needed to gradually augment the base card. In the following example, four upgrades have been applied in sequence to the base level of cr1600g to bring the XMA from CR to ER then ER to HE then to increase capacity first from 1600 Gb/s to 2400 Gb/s and then from 2400 Gb/s to 2400 Gb/s with aggregation to 3600 Gb/s.
===============================================================================
MDA 1/1 detail
===============================================================================
Slot Mda Provisioned Type Admin Operational
Equipped Type (if different) State State
-------------------------------------------------------------------------------
1 1 s36-100gb-qsfp28:cr1600g up provisioned
(not equipped)
MDA Licensing Data
Licensed Level : he2400g+
Description : 2.4T /w agg to 3.6T, 36p, High Scale Edge
Routing
Upgrade 1 : cr1600g-er1600g
Upgrade 2 : er1600g-he1600g
Upgrade 3 : he1600g-he2400g
Upgrade 4 : any2400g-2400g+
Oversubscribed Ethernet MDAs
The 7750 SR and 7450 ESS support oversubscribed Ethernet MDAs. These have more bandwidth toward the user than the capacity between the MDA and IOM.
A traffic management function is implemented on the MDA to control the data entering the IOM. This function consists of two parts:
rate limiting
packet classification and scheduling
Rate limiting
The oversubscribed MDA limits the rate at which traffic can enter the MDA on a per-port basis. If a port exceeds its configured limits then the excess traffic is discarded, and 802.3x flow control frames (pause frames) are generated.
Packet classification and scheduling
The classification and scheduling function implemented on the oversubscribed MDA ensures that traffic is correctly prioritized when the bus from the MDA to the IOM is overcommitted. This could occur if the policing parameters configured are such that the sum of the traffic being admitted into the MDA is greater than the capacity between the MDA and the IOM.
The classification function uses the bits set in the DSCP or Dot1p fields of the customer packets to perform classification. It can also identify locally addressed traffic arriving on network ports as Network Control packets. This classification on the oversubscribed MDA uses the following rules:
If the service QoS policy for the SAP (port or VLAN) uses the default classification policy, all traffic is classified as Best Effort (
be).If the service QoS policy for the SAP contains a Dot1p classification, the Dot1p field in the customer packets is used for classification on the MDA.
If the service QoS policy for the SAP contains a DSCP classification, the DSCP field in the customer packets is used for classification on the MDA.
If a mix of Dot1p and DSCP classification definitions are present in the service QoS policy, then the field used to perform classification is the type used for the highest priority definition. For example, if High Priority 1 is the highest priority definition and it specifies that the DSCP field should be used, then the DSCP field is used for classification on the MDA and the Dot1p field is ignored.
If the service QoS policy for the SAP specifies IP or MAC filters for forwarding class identification, then traffic is treated as Best Effort. Full MAC or IP classification is not possible on the MDA (but is possible on the IOM).
The packet is classified into 16 classes. Typically, these are the eight forwarding classes and each packet is assigned one priority per forwarding class. After classification, the packet is offered to the queuing model. This queuing model is limited to three queues each having four thresholds. These thresholds define whether an incoming packet, after classification, is accepted in the queue or not. Typical mapping of classes onto queues/threshold shows typical mapping of classes onto queues and thresholds.
Table 1. Typical mapping of classes onto queues/threshold Counter {Queue Threshold Traffic class} 0
{2
3
‟fc-nc / in-profile”}
1
{2
2
‟fc-nc / out-profile”}
2
{2
1
‟fc-h1 / in-profile”}
3
{2
0
‟fc-h1 / out-profile”}
4
{1
3
‟fc-ef / in-profile”}
5
{1
2
‟fc-ef / out-profile”}
6
{1
1
‟fc-h2 / in-profile”}
7
{1
0
‟fc-h2 / out-profile”}
8
{0
3
‟fc-l1 / in-profile”}
9
{0
3
‟fc-l1 / out-profile”}
10
{0
2
‟fc-af / in-profile”}
11
{0
2
‟fc-af / out-profile”}
12
{0
1
‟fc-l2 / in-profile”}
13
{0
1
‟fc-l2 / out-profile”}
14
{0
0
‟fc-be / in-profile”}
15
{0
0
‟fc-be / out-profile”}
A counter is associated with each mapping. The above is an example and is dependent on the type of classification (such as dscp-exp, dot1p, and so on). When the threshold of a particular class is reached, packets belonging to that class are not accepted in the queue. The packets are dropped and the associated counter is incremented.
The scheduling of the three queues is done in a strict priority, highest priority basis is associated with queue 2. This means that scheduling is done at queue level, not on the class that resulted from the classification. As soon as a packet has been accepted by the queue there is no way to differentiate it from other packets in the same queue (for example, another classification result not exceeding its threshold). All packets queued in the same queue, have the same priority from a scheduling point of view.