Nortel Networks 5530 Manual Do Utilizador
Filters and QoS Configuration for ERS 5500
Technical Configuration Guide
Technical Configuration Guide
v2.0
NN48500-559
___________________________________________________________________________________________________________________________
Nortel Confidential Information Copyright © 2008 Nortel Networks. All Rights Reserved.
External Distribution
10
3. Filter
Functionality
3.1 Overall
Classification
Functionality
Classification with the Ethernet Routing Switch 5500 has some fundamental classification
limitations, imposed by hardware, that affect classification overall. The foremost limitation is
related to the concept, introduced by the latest classification hardware and the supporting data
model, of “classification masks”. A classification mask specifies the fields within a frame that will
be used for matching purposes. The mask itself does not specify the data to be matched but
rather indicates which fields, or portions thereof, in the various protocol headers (e.g., MAC, IPv4,
IPv6 headers) will be examined during the classification process. Currently, a maximum of 15
classification masks and 114 classifiers are available per port for user-defined traffic
classification. This effectively means that 15 or fewer unique combinations of classification criteria
(i.e., Layer 2, 3 and 4 data) can be specified per port. However, multiple data sets can leverage
the same classification mask. This means that, as long as the same protocol data fields are being
matched (e.g., IPv4 source address, IPv6 flow label, Layer 2 802.1p User Priority and VLAN Id), a
much larger number of classifiers, up to a maximum of 114 per port, can be defined containing
unique data values for matching against the fields/offsets identified by the classification mask.
limitations, imposed by hardware, that affect classification overall. The foremost limitation is
related to the concept, introduced by the latest classification hardware and the supporting data
model, of “classification masks”. A classification mask specifies the fields within a frame that will
be used for matching purposes. The mask itself does not specify the data to be matched but
rather indicates which fields, or portions thereof, in the various protocol headers (e.g., MAC, IPv4,
IPv6 headers) will be examined during the classification process. Currently, a maximum of 15
classification masks and 114 classifiers are available per port for user-defined traffic
classification. This effectively means that 15 or fewer unique combinations of classification criteria
(i.e., Layer 2, 3 and 4 data) can be specified per port. However, multiple data sets can leverage
the same classification mask. This means that, as long as the same protocol data fields are being
matched (e.g., IPv4 source address, IPv6 flow label, Layer 2 802.1p User Priority and VLAN Id), a
much larger number of classifiers, up to a maximum of 114 per port, can be defined containing
unique data values for matching against the fields/offsets identified by the classification mask.
3.2 Classifier
Block
Functionality
A user should take care when grouping a large number of individual classifiers into a classifier
block. Grouping is a quick way to inadvertently exhaust limited resources. For example, a limited
number of counters are available per interface for tracking matching/in-profile packets.
Associating a block of classifiers with a policy indicating that statistics are to be maintained could
consume all counting resources for a single interface with one policy. To avoid exhausting the
number of counters available per interface, one may select "aggregate classifier tracking" instead
of "individual classifier tracking" when creating the policy. By specifying "aggregate classifier
tracking", a single counter resource is used to track statistics for all the classifiers of that policy,
rather than a single counter resource per classifier. The obvious downside to this is the inability
to track the statistics down to the granularity of each of the classifiers associated with the policy.
Individual attribute limitations include:
block. Grouping is a quick way to inadvertently exhaust limited resources. For example, a limited
number of counters are available per interface for tracking matching/in-profile packets.
Associating a block of classifiers with a policy indicating that statistics are to be maintained could
consume all counting resources for a single interface with one policy. To avoid exhausting the
number of counters available per interface, one may select "aggregate classifier tracking" instead
of "individual classifier tracking" when creating the policy. By specifying "aggregate classifier
tracking", a single counter resource is used to track statistics for all the classifiers of that policy,
rather than a single counter resource per classifier. The obvious downside to this is the inability
to track the statistics down to the granularity of each of the classifiers associated with the policy.
Individual attribute limitations include:
•
Individual classifier identification – a classifier set must exist prior to being referenced by
the Classifier-Block.
the Classifier-Block.
•
Individual classifier data compatibility – a classifier is eventually broken down into a
bitmask identifying fields in a packet header that are of interest and values to be matched
against those fields. Classifiers within a block must match the same protocol header
fields, or portions thereof. For example, all classifiers in a block must match against an
IPv4 source host address, an IPv4 source subnet with the same number of significant bits
or the Layer 2 EtherType field in a tagged packet. A classifier matching against an IPv4
source host address and another matching against an IPv4 destination host address may
not be members of the same block as these classifiers do not share a common
classification mask. The values to be matched against may differ but the fields being
matched may not.
bitmask identifying fields in a packet header that are of interest and values to be matched
against those fields. Classifiers within a block must match the same protocol header
fields, or portions thereof. For example, all classifiers in a block must match against an
IPv4 source host address, an IPv4 source subnet with the same number of significant bits
or the Layer 2 EtherType field in a tagged packet. A classifier matching against an IPv4
source host address and another matching against an IPv4 destination host address may
not be members of the same block as these classifiers do not share a common
classification mask. The values to be matched against may differ but the fields being
matched may not.
Referenced component consistency – all the elements that comprise a block (i.e., all classifier
blocks with the same block number) must either reference an action or a meter component or
none of the elements are permitted to reference an action or a meter. In other words, all block
members must specify the same type of information, be it action criteria, metering criteria or
neither. The referenced action or metering elements may differ across block members but all
members must reference individual actions or meters (but not actions and meters) if any do.
blocks with the same block number) must either reference an action or a meter component or
none of the elements are permitted to reference an action or a meter. In other words, all block
members must specify the same type of information, be it action criteria, metering criteria or
neither. The referenced action or metering elements may differ across block members but all
members must reference individual actions or meters (but not actions and meters) if any do.