SAP access ingress policies

General Information

SAP access ingress policies are applied to access interfaces and specify QoS on ingress.

SAP access ingress policies define ingress service forwarding class queues and map flows to those queues. When an access ingress policy is created, it always has two queues defined that cannot be deleted: one for the default unicast traffic and one for the default multipoint traffic. These queues exist within the definition of the policy. The queues only get instantiated in hardware when the policy is applied to an access interface. In the case where the service does not have multipoint traffic, the multipoint queue is not instantiated.

In the simplest access ingress policy, all traffic is treated as a single flow and mapped to a single queue, and all flooded traffic is treated with a single multipoint queue.

The required SAP access ingress policy elements include:

The optional SAP access ingress policy elements include:

Each queue can have unique queue parameters to allow individual policing and rate shaping of the flow mapped to the forwarding class. Mapping flows to forwarding classes is controlled by comparing each packet to the match criteria in the policy.

There is one default SAP access ingress policy. The default policy gives all traffic equal priority with the same chance of being sent or dropped during periods of congestion.

Note: The NFM-P supports the configuration of HQoS scheduling mechanisms. HQoS provides the ability to rate limit across multiple queues from single or multiple access interfaces for a specific customer. The building blocks for HQoS include access ingress, access egress, and scheduler policies.

See Sample network QoS configuration for a sample service configuration using HQoS.

Policy override

You can override some or all settings associated with an access ingress policy on an L2 or L3 access interface, SLA profile, or subscriber profile. See To configure QoS policy overrides on an L2 or L3 access interface.

Note: You can override SAP access ingress policies that have the Scope parameter set to template; see To configure a SAP access ingress policy.

Tagged IP/IPv6 match entry overrides

In a SAP access ingress policy, you can assign a numbered tag identifier to IP and IPv6 match criteria entries. When the SAP access ingress policy is assigned to an L2 or L3 SAP, you can configure a QoS policy override to use the tag identifiers to select tagged entries with the same identifier. Any untagged entries in the policy are still valid on the SAP. The IP or IPv6 Criteria Type in the SAP access ingress policy must be set to Tagged Entries.

The following task flow lists the basic steps required to enable tagged IP/IPv6 match entry overrides.

  1. Plan the match criteria and tag mapping as required.

  2. Create a SAP access ingress policy and set the IP or IPv6 Criteria Type parameters in the policy to Tagged-Entries; see To configure a SAP access ingress policy.

  3. In the same policy, create IP or IPv6 match criteria entries and assign tag IDs to the entries.

  4. Distribute the policy to NEs that support tagged match entries.

  5. For the required L2/L3 SAPs, configure a QoS policy override to define the tag IDs to use on the SAP; see To configure QoS policy overrides on an L2 or L3 access interface.

Forwarding classes

The NFM-P supports the configuration of eight forwarding classes and class-based queuing or policing on the managed devices. Each forwarding class is only important in relation to other forwarding classes. A forwarding class provides NEs with a method to determine the relative importance of one packet over another packet in a different forwarding class.

Queues are created for a specific forwarding class to determine how the queue output is scheduled into the switch fabric and the type of parameters that the queue accepts. The forwarding class of the packet, and the in-profile and out-of-profile states, determine how the packet is queued and handled at each hop along its path to a destination egress point. Forwarding classes may also be associated with policers instead of queues. Eight forwarding classes are supported. The table below lists the default definitions for the supported forwarding classes.

Although all forwarding classes support profile marking, it is a good network engineering practise to ensure that all high priority forwarding classes are in-profile (CIR=PIR) and all low priority forwarding classes are out-of-profile (PIR > CIR=0). This way, distinguishing packets as in-profile or out-of-profile only occurs for assured class types.

Table 50-1: Forwarding classes

Forwarding class ID

Forwarding class name

Forwarding class designation

DiffServ name

Class type

Intended

7

Network control

nc

nc2

High priority

For network control traffic

6

High-1

h1

nc1

For a second network control class or delay/jitter sensitive traffic

5

Expedited

ef

ef

For delay/jitter sensitive traffic

4

High-2

h2

h2

For delay/jitter sensitive traffic

3

Low-1

l1

af2

Assured

For assured traffic; default priority for network management traffic

2

Assured

af

af1

For assured traffic

1

Low-2

l2

cs1

Best effort

For best effort traffic

0

be

be
Forwarding subclasses

You can use forwarding subclasses for additional access ingress packet classification. One or more subclasses can be associated with each forwarding class. The designations for forwarding subclasses are the same as those for the forwarding classes listed in Table 50-1, Forwarding classes . Each subclass assumes the behavior of its parent forwarding class. and in combination with the forwarding class provides a greater range of access ingress QoS classification possibilities.

Enabling ETH-LMM Y.173 statistics based on QoS forwarding classes

The ETH-LMM Y.1731 approach to Ethernet frame loss measurements allows for the collection of frame counters in order to determine the unidirectional frame loss between point-to-point ETH-CFM MEP peers. See the supported NE OAM and Diagnostics guide for more information about the ETH-LMM Y.1731 protocol.

You can enable the collection of ETH-LMM Y.1731 statistics on the NFM-P based on eight forwarding classes (either profile aware, or profile unaware) for the following Service types: EPIPE, VPLS, VPRN, and IES. Use the Collect ETH-LMM FC Stats parameter or Collect ETH-LMM FC Stats in Profile parameter on the supported Services navigation tree toolbar to enable ETH-LMM Y.1731 statistics collection as follows:

See the XML API Reference for information about configurable parameters, their applicability, and the NFM-P GUI forms from which the parameters can be accessed.

Policers

You can add a policer to an access ingress policy to provide traffic flow limiting. Policers are associated with the forwarding classes defined in the access ingress policy. Policers can also be linked to a policer control policy, which maintains a hierarchy of multiple policer objects in the NFM-P system. Policers are linked to policer control policies by means of an arbiter. For more information, see Policer control policies.

When policers are configured in an access ingress policy, they can be used to generate statistics. The type of statistics generated depends on the Stats Mode. The following table lists the options for counter allocation when generating statistics:

Table 50-2: Stats Mode options

Option

Description

No Override

The system does not override the value of Stats Mode set in the policer control policy.

Minimal

The system creates one offered-output counter in the network processor and one discard counter in the QChip. Packet priority, initial profile, and CIR profile output are ignored, and are not individually visible in the policer statistics.

Use the Minimal option when only basic policer accounting is required.

No Stats

The system does not allocate any counters to the policer. The absence of counters does not affect the operation of the policer.

Use the No Stats option when policer accounting is not required. You cannot enable this option if the policer has a parent arbiter assigned to it.

Offered Limited Capped CIR

The system creates two offered-output counters in the network processor and two discard counters in the QChip.

Use the Offered Limited Capped CIR option when ingress packets are being classified as either in-profile, or ignored when the traffic is in excess of CIR. Packet priority is ignored, and is not separated in the accumulated statistics.

Offered Limited Profile CIR

The system creates three offered-output counters in the network processor and three discard counters in the QChip.

Use the Offered Limited Profile CIR option when ingress color-aware profiling is in use but packets are not being classified as in-profile. In most color-aware instances, only undefined and explicit out-of-profile packets are used in service offerings. If an in-profile classified packet is offered to the policer, it is included in the offered-undefined statistic. Packet priority is ignored, and is not separated in the accumulated statistics.

Offered Priority CIR

The system creates four offered-output counters in the network processor and four discard counters in the QChip.

Use the Offered Priority CIR option when the ingress policer is used on a non-color-aware mode (all ingress packets have an undefined initial profile), but packet priority input and CIR state output visibility is required.

Offered Priority No CIR

The system creates two offered-output counters in the network processor and two discard counters in the QChip.

Use the Offered Priority No CIR option when ingress packet priority (high profile and low profile classification) accounting is the primary requirement. The initial and output profile of the packets offered to the policer is ignored in the offered, discarded, and forwarded statistics. This mode does not inhibit the function of CIR on the ingress policer and it does not prevent explicit in-profile and out-of-profile classification for packets offered to the policer.

Offered Profile Capped CIR

The system creates three offered-output counters in the network processor and three discard counters in the QChip.

Use the Offered Profile Capped CIR option when ingress packets are being marked as either in-profile, or out-of-profile when the traffic is in excess of CIR. Packet priority is ignored, and is not separated in the accumulated statistics.

Offered Profile CIR

The system creates four offered-output counters in the network processor and four discard counters in the QChip.

The Offered Profile CIR option is similar to the Offered Limited Profile CIR option, except that it includes the in-profile packet classification along with the out-of-profile and undefined-profile classifications. As with the Offered Limited Profile CIR option, packet priority is ignored and not separated in the statistics.

Offered Profile No CIR

The system creates two offered-output counters in the network processor and two discard counters in the QChip.

Use the Offered Profile No CIR option when all ingress packets are either in-profile or out-of-profile. Undefined-profile packets are treated as offered out from a statistics perspective. Undefined-profile packets are affected by the current state of the policer's CIR and are output as either in-profile or out-of-profile, depending on the CIR output state. The offered, discarded, and forwarded statistics do not reflect this behavior because they are based on the initial profile of the packets.

Offered Total CIR

The system creates two offered-output counters in the network processor and two discard counters in the QChip.

Use the Offered Total CIR option when ingress priority and initial profile visibility is not required, and CIR profiling is in use. In many cases, all packets offered to a policer are of one priority level and all have the same initial profile (in-profile, out-of-profile, or undefined-profile). This option is different from the Minimal option because it provides visibility into the policer's CIR output.

Traffic mapping

You can specify the mapping between the ingress traffic and the ingress queue. Mapping is optional and can be based on combinations of customer QoS marking (dot1p, DSCP, LSP-EXP, and Precedence), and IP criteria, Ipv6 criteria, or MAC criteria. See the table below.

Adding an LspExp rule to a policy forces packets that match the specified MPLS LSP EXP criteria to override the existing forwarding class and enqueuing priority, based on the parameters specified in the LspExp rule. This functionality allows geographically distributed ISP sites to establish site-to-site interconnection service through a backbone network using VPLS/VLL. Each ISP site PE router connects to a 7x50 Ethernet L2 SAP in the backbone network, and traffic is encapsulated in a VPLS/VLL service tunnel. A maximum of eight LspExp rules are allowed on a single access ingress policy.

Table 50-3: SAP access ingress policy traffic mapping

Tab

Function

Dot1p

Maps the dot1p value of the ingress traffic to the ingress queue ID

DSCP

Maps the DSCP value of the ingress traffic to the ingress queue ID

LspExp

Maps the EXP value of the ingress traffic to the ingress queue ID

Precedence

Maps the precedence value of the ingress traffic to the ingress queue ID

IP Match Criteria

Maps the IP Match Criteria of the ingress traffic to the ingress queue ID

IPv6 Match Criteria

Maps the IPv6 Match Criteria of the ingress traffic to the ingress queue ID

MAC Match Criteria

Maps the MAC Match Criteria of the ingress traffic to the ingress queue ID