ISAM QoS Policing Shaping

QoS in ISAM – Module 2Policing & Shaping

Victor Cortijo

EMEA S&M – Fixed Access DBC

BB Access Expert Technical Pre-sales

June 2010

2 | ISAM forwarding Telenor | March 2009 All Rights Reserved © Alcatel-Lucent 2009, XXXXX

Context – ISAM Forwarding Discovered

This module is part of a series of training modules on forwarding in ISAM.

The series is created in partnership between ALU University and the EMEA S&M Fixed Access DBC (Domain Business Center)

The modules are made available via 2 channels:

ALU University Learning2.Go

EMEA Fixed Access DBC Portal

Alcatel Lucent University

Learning2.GO

EMEA Solutions & Marketing

Fixed Access DBC

Broadband Access “Discovered”


Target AudienceHow to use these slides

This is an Alcatel-Lucent internal training module

Prime target audience of this module are (technical) pre-sales people who are looking for in depth understanding of the QoS feature in ISAM

The material in this presentation can – in general – be reused in customer presentations, however this will require some adaptations. The module has NOT been designed to be presented as such to customers.

This training module is NOT an operator course. If you are looking for a training on how to operate the ISAM, dedicated courses are available from ALU University.

This module is available in 2 formats

Powerpoint slideset

Recorded audio with slides


Objectives of this Module

After attending this module, you will:

understand the QoS policing and shaping features available in ISAM R4.2 for the SHUB NT and the standard LT cards.

be able to discuss these features with customers.

The goal of this training module is not so much explaining the technology (e.g.

exact working of TrTCM, which can be learnt via books or courses) but explaining

what features are available in ISAM, the reasons behind and how they are

organized or handled. The idea is to present a visual 'enciclopaedia' (to a certain

level) of ISAM QoS so that the exact functionality may be further explored if so

desired.


Prerequisite Knowledge

This module assumes that the student:

has basic understanding of the ISAM product family

has a basic knowledge of Ethernet/VLAN technology

•If you haven’t done so yet, it may be a good idea to have a look first to the

following training modules:

•Competency pick-up on forwarding

•ISAM QoS Marking


Important Notes

This module was created in May, 2010.

Consequently it describes the ISAM functionality as available in release 4.2

As the ISAM product evolves, features may be subject to change. For actual up to date information on system functionality, make sure to check the product roadmap information.

In particular…

Both the new R4.0.02 NANT-D and the new R4.2 NANT-E have a different QoS treatment than the standard NANT-A since they are based on the new IHUB switching block. They will be described in a specific training module.

The new R4.0.10 NGLT-A/NGLT-B cards present some differences with respect to the standard LT cards as described in this presentation. These differences are described in a specific training module.

This module is the second one of a series of six on ISAM QoS functionality. This second module describes the generic policing and shaping functionality for the SHUB NT and the standard LT cards.


Agenda

1. QoS basics – policing & shaping

2. ISAM QoS – policing & shaping

3. Conclusions


QoS basics – policing & shaping1


QoS

Network dimensioning

In the first QoS module we learnt how to differentiate traffic by using marking.

So, the nodes will use the marking information to handle correctly the traffic (which, in a DiffServ architecture, means that lower priority traffic will be dropped before higher priority traffic if congestion happens).

But.. Still the goal would be not having any sustained packet loss at any node, right?

Question: How can operators ensure that there is no sustained packet loss at one node?

Answer: They need to dimension the network correctly for sustained traffic throughput.

So, how do they know what the sustained traffic throughput is?

•Statistical approach (they know how much a user typically sends and receives).

This is ok for normal, residential users, whose habits are well studied and known.

•Service Level Agreements (they sign special agreements with users limiting the

amount of traffic). This is specially true in wholesale environments where ‘users’

need to pay for the amount of network they are using.


Policing/shaping concepts

Why?

For services, end-customers or interfaces that are contractually or physically binded to a certain treatment.

Shaping is not recommended for

voice flows since it will impact the end-

to-end delay

Traffic IN Traffic OUT

PolicerBurst tolerance = 0

PolicerBurst tolerance = 0

Shaper

BW

time

Needed for both policing and shaping:- a classifier to differentiate the flow to be policed/shaped- a meter to meter the flow in time-an action based on the result of the metering (normally discard/delay or pass)

A policer will drop the not-conforming traffic while a shaper will delay the same traffic. The difference is explained graphically below. Shaping always involves queueing (which means delay)

Several ways to do policing and shaping:

single/dual token bucket, single/dual rate three colour

marking



Single token bucket

Single token bucket policing/shaping is the easiest one.Two parameters:-token accumulation rate (Commited Information Rate or CIR)-burst tolerance (Commited Burst Size or CBS)

Single token bucket policing is not appropriate for TCP traffic. The reason is that TCP traffic has flow control rules triggered

by packet delay. Since policing does not introduce delays, many packets are lost when using single token bucket policing

until the flow control limits the TCP traffic.

Tokens:-represent traffic volume (bucket stores tokens, never actual data).-accumulate at constant pace (until the bucket is full), representing traffic allowed per time period.-are removed when traffic arrives to the meter (exactly an amount that corresponds to the size of the packet)

Packets that arrive to the meter at a moment when there are sufficient tokens in the bucket corresponding to its size are declared ‘Conforming’ or ‘In Profile’.

Also known as 1R2C



Dual token bucket

Dual token bucket policing/shaping is a refined version of the single token bucket.Four parameters:-normal token accumulation rate (Commited Information Rate or CIR)-normal burst tolerance (Commited Burst Size or CBS)-peak token accumulation rate (Peak Information Rate or PIR)-peak burst tolerance (Peak Burst Size or PBS)

Dual token bucket policing/shaping is useful for traffic with big burst size values.

The philosophy is exactly the same but, while in the single token bucket the packets can burst at any speed (provided that enough tokens remain in the bucket), in the dual token bucket, the packets can only burst at the controlled rate marked by the PIR.

The conformance condition requires both buckets to have sufficient tokens to match the size of a newly arriving packet. If at least one of the buckets have insufficient tokens then the packet is non-conforming and tokens are removed from neither buckets.



Single rate three colour marking (SrTCM)

Single rate three colour marking uses the concept of a main token bucket and an ‘excess’ tokens bucket.Four parameters:-normal token accumulation rate (Commited Information Rate or CIR)-normal burst tolerance (Commited Burst Size or CBS)-excess burst tolerance (Excess Burst Size or EBS)-color-mode flag (to define if the policer/shaper is working in color-blind or color-aware mode)

Also known as 1R3C (RFC2697)

Three conformance levels (color-blind mode):-Green - when sufficient tokens are present in bucket B1-Yellow - when B1 has insufficient tokens, but B2 has-Red - when neither B1 nor B2 have sufficient tokens The only difference in color-aware mode is that incoming colour marking is taken into account (green packets are checked against both buckets (and marked accordingly), yellow packets are only checked against B2 (so they can continue being yellow or become red) and red packets are always non-conforming (and remain red))



Two rate three colour marking (TrTCM)

Two rate three colour marking is a mixture of Single Rate Three Colour Marking and a dual token bucket.

Colour marking is often used in

the BAC mechanism to

drop traffic (WRED)

Three conformance levels (color-blind mode):-Green - when sufficient tokens are present in both buckets (tokens are removed from both)-Yellow - when CIR bucket has insufficient tokens, but the PIR bucket has (tokens are removed from PIR bucket)-Red - when neither CIR nor PIR buckets have sufficient tokens The only difference in color-aware mode is that incoming colour marking is taken into account (green packets are checked against both buckets (and marked accordingly), yellow packets are only checked against PIR bucket (so they can continue being yellow or become red) and red packets are always non-conforming (and remain red))

Five parameters:-normal token accumulation rate (Commited Information Rate or CIR)-normal burst tolerance (Commited Burst Size or CBS)-peak token accumulation rate (Peak Information Rate or PIR)-peak burst tolerance (Peak Burst Size or PBS)-color-mode flag (to define if the policer/shaper is working in color-blind or color-aware mode)

CIR

CBS

Ingresstraffic

Red Traffic

Passedtraffic

PIR

PBS

Also known as 2R3C (RFC2698)


ISAM QoS – policing &

shaping2


QoS

ISAM Architecture – schematic overview

LT n

NT**

1

n

direct Ethernet i/f

LT 1

…

subtending i/f

…

NT I/O (optional)Additional uplink

interfaces

Up

lin

ks

Several multiDSL lines per LT card

Ethernet aggregation

Control function

ONT*

*Since R4.2 onwards, ISAM supports the GPON-technology NGLT-A/B line cards and hence ONTs. The NGLT-A/B QoS features are the objective of a specific training module.

** Since R4.0.02, ISAM supports a new type of High Capacity NTs (the NANT-D/NANT-E(R4.2)). These cards feature a new switching block called the IHUB instead of the previous SHUB. The IHUB QoS features are the objective of a specific training module.


QoS

QoS profiles

For reasons that we will see in following slides, the

QoS treatment at the LT cards is somewhat more

complicated that the one at the NT card. For this

reason, and to help with the reusability of the

QoS provisioning, the LT cards make use of the

concept of QoS profiles, a common set of QoS

characteristics that are later applied to different

subscribers.

Actor

(CLI/AWS/

Radius)

QoS mgmt

NTQoS MIB

1

2

3

4

This ‘QoS session profile’ is thoroughly explained in a dedicated module but, all

throughout the next slides, it is pointed out when a specific LT QoS feature is applied

through a QoS session profile or is applied directly over the subscriber interface entity.

The SHUB NT QoS settings are always applied directly over the NT

interfaces. They never make use of the QoS session profile settings.

This concept of ‘QoS profiles’ is implemented through a generic entity called a ‘QoS session profile’.


QoS

Basic policing cases

A) Ingress policing of upstream traffic coming from the user is the most important policing action. It assures that users are not sending more traffic into the network than allowed by their subscription*.

Ingress policing is normally

driven by pure commercial

considerations though

sometimes fairness between

users can also be important.

B) On top of being a traffic limitation feature, ingress policing can also be seen as a security feature (implementing ACLs), which basically means a discard/pass choice of the policed traffic.

*Typically, the requirement is to police per service. Depending on the network model, this can be realised in different ways:• In a multi-PVC/multi-VLAN model, typically the operator will choose to apply policing per PVC/VLAN.• In a single PVC/VLAN model, the operator will probably police per IP destination address, which implies subflow filtering.** While subscribers are normally connected to subscriber interfaces at the LTs, it may happen ocassionally that some business

subscribers are directly connected to the NT. For these subscribers, the SHUB NT interfaces also support ingress policing.

Ingress policing at subscriber interfaces (per SAP and per subflow) is the main requirement for this case**.

Notice that for these two cases, discarding the out-of-profile traffic is allowed.

Hence, policing is used instead of shaping (so that it does not introduce extra delay).


QoS

Basic shaping cases (1)

A) Tuning egress traffic to fit the network capacity is the most important shaping action* e.g. an ISAM GE is connected to a node that can handle only 600 Mbps.

In this case, it is clear that the main goal is trying to maximize the

capacity of the link (already limited per se). Due to this, shaping is

normally applied instead of policing.B) Enforcing SLAs for aggregate egress traffic is the second case in which shaping is applied. This is normally done in wholesale environments in which the network owner rents a specified capacity to a service provider.

*Notice that this is true for either uplinks (connected to network nodes) or subtended nodes (other DSLAMs) but, in any case, NT interfaces.

** Using shaping could adversely impact the voice traffic quality (if present) due the extra delay added. To solve this, shaping per VLAN at the NT would be required. However, this is not implemented in the SHUB NTs.

In this case, the goal is not to maximize capacity (out-of-profile traffic

can be dropped) so egress policing could be used. However, since the

SHUB NT policers are single token bucket, to avoid problems with TCP

traffic, it is better to use shaping for this case**.

Egress shaping at SHUB NT interfaces is the main requirement for this.


QoS

Basic shaping cases (2)

C) Enforcing SLAs for subscriber egress traffic is the third case in which shaping is applied. This is normally done for specific services and not for the whole subscriber line.

* Using shaping could adversely impact voice traffic (if present) due the extra delay added. Implementing shaping per queue at the LT card subscriber interfaces is a way to solve this problem.

** Notice that downstream per queue shaping at the subscriber interfaces is only supported since R4.1.02 and only for new generation line cards (as of R4.2, the NVLT-G/H and all the new VDSL2 line cards derived from it and the NELT-B). The NGLT-A card also has per queue downstream shapers but they will be explained in the specific NGLT-A QoS module.

Per SAP egress policing is supported at the LT cards. However, since the

ISAM LT cards policers are single token bucket, to avoid problems with

TCP traffic, it is better to use shaping for this case*.

Egress shaping at the subscriber interfaces** is the main requirement for this.


Policing/shaping at LTs


QoS

Policing at the LTs (downstream and upstream)

Applying policing at the LTs subscriber interfaces is done by either:

A) creating a QoS session profile that includes a policer profile (upstream and/or

downstream) and attaching it to the SAP*.

B) Creating a QoS session profile that includes a subflow filter and a policer profile (to

be applied to that subflow, upstream and/or downstream) and attaching it to the SAP*.

Guidelines (discussed in detail in the QoS session profile module)

The policing settings come only from the QoS session

profile. There are no static policing settings provisioned

directly at the SAP.

*SAPs in ISAM are:• bridge-ports (subscriber PVCs (ATM) or ports (Ethernet/PTM)).• VLAN-ports (bridge-ports with a subscriber VLAN associated to them; always set on top of bridge-ports)• PPP client ports (connection to a PPP forwarder; can be set on top of either a VLAN-port or the DSL port).

Both policing settings (at SAP level and subflow level) can coexist in the same QoS sesion

profile. In this case, obviously, the subflow settings have precedence over the SAP level for

that specific subflow.


QoS

Shaper profiles at the LTs (only downstream)

Shaper profiles are used to configure the shaper settings per queue.

Scheduler configuration occurs by associating a shaper profile to one or more queues.

The max number of

shaper profiles at

any moment in time

is 128 per ISAM.

The shaper profile contains the CIR and the CBS parameters of the shaper (notice that the shapers are all single token bucket) with the following constraints:

CIR : 32Kbps to 128Mbps

CBS: 256 bytes to 256Kbytes

WFQ

voice

video

CL

BE

SPShaper

Shaper

Shaper

Shaper

* The EIR (Excess Information Rate) value is used for the NGLT-A shapers and will be explained in the FD GPON QoS module.** The shaper type is always SingleTokenBucket except for the NGLT-A shapers. This will be explained in the FD GPON QoS

module.

Shaper Profile Name

CIR CBS EIR* Type**

Shaper_prof11000 6000 0 SingleTokenBucket

Shaper_prof2 64000 SingleTokenBucket

Shaper_prof3600

48000 SingleTokenBucket

Shaper_prof410000

50000 SingleTokenBucket

8000


Policing/shaping at SHUB NT


QoS

Ingress policing at the NT

Applying ingress policing at the SHUB NT external interfaces is done by:

A) creating a NT interface flow with the following characteristics:

• Flow type (port, VLAN, VLAN+specific P-bits, VLAN+specific DSCP-bits)• VLAN ID (if needed)• P-bits (if needed)• DSCP-bits (if needed)

B) creating a NT policer entity, defined by 1) CIR : 1Kbps to 10Gbps (or the

maximum rate of the interface) in increments of 64Kbps and 2) CBS: 3Kbytes to

512Kbytes coded as [0..7] (8 discrete values)

C) attaching both the NT interface flow and the NT policer to one of the SHUB NT external physical interfaces.

Ingress policing at SHUB NT interfaces is not a common case and it is only

supported so that users connected directly to the NT have some ingress

policing capability. The main interest for this case is in a wholesale

environment in which the network owner wants to limit the bandwidth offered

to a service provider connected directly to a NT port.

Up to a maximum total of 64 flows

and policers can be created per

SHUB NT.

Up to 16 policers can be attached to a single SHUB NT

interface.


QoS

L2 ingress filtering at the NT*

Applying L2 ingress filtering at the SHUB NT interfaces is done by:

creating a NT L2 filter with the following characteristics (only ingress direction):

• Index number• Port (type and number of the ports to which the filter is applied)• MAC SA/MAC DA• VLAN ID• Ethertype• Action (drop)

* While filtering is not strictly a QoS mechanism (more like a security one), since it has been explained as a QoS feature for the LTs, it is explained here also as part of the NT QoS features.

The index number implements also the precedence rule for the case in which

several filters are applied at the same port. The lower the index number, the

higher the precedence of the filter.

Up to a maximum total of

128 L2 filters can be defined

per NT.


QoS

L3 ingress/egress filtering at the NT* for specific IP protocols

Applying ICMP/UDP/TCP L3 filtering at the SHUB NT interfaces is done by:

A) creating a NT L3 filter for an specific IP protocol with the following characteristics:

• Filter type (TCP, UDP, ICMP)• Index number• IP DA/IP SA and masks• Protocol-dependant attributes (msg-type, msg-code, dst-port range, src-port range,

ack, rst, tos) • VLAN ID• Direction (in/out)• Action (drop) – this is not supported for filters in out direction

B) Applying the created L3 filter to a list of ports (either in input or in output direction).


Up to a maximum total of 128 L3

filters can be defined per SHUB

NT.





QoS

L3 ingress/egress filtering at the NT* for other IP protocols

Applying a other-protocol L3 filtering at the SHUB NT interfaces is done by:

A) creating a NT L3 filter (in ingress/egress direction) with the following characteristics:

• Index number• Port (type and number of the ports to which the filter is applied)• IP DA/IP SA and masks• Protocol (IGMP, RSVP, MSRP, OSPF,..,any) • VLAN ID• Action (drop) – this is not supported for filters in egress direction


Up to a maximum total of 128 L3

filters can be defined per SHUB

NT.





QoS

Egress shaping at the SHUB NT

Applying egress shaping at the SHUB NT external interfaces is done by:

Applying a shaping rate to the SHUB NT external physical interface. The shaping

rate is specified in increments of 64Kbps with a range between 1Kbps and 10Gbps

(or the maximum rate of the interface).

Notice that egress shaping per VLAN at the SHUB NT external interfaces

would really fulfill the requirement in a true wholesale environment in which

several service providers can share the bandwidth offered by one of the NT

external interfaces. Also, it would solve the problem of the extra delay caused by

shaping to voice flows. This feature is not implemented in the SHUB NT.

The egress shaping rate is applied directly as part of the characteristics of the

SHUB NT ports and, as such, does not consume any system resources. Hence,

shaping can always be applied to the SHUB NT ports without any dimensioning

limitation.


Conclusions3


Conclusions

In this module you have learned:

In which way ISAM supports QoS policing and shaping for the SHUB NT and the standard LT cards.

Ingress/egress policing at the LT cards applied through a QoS Session Profile.

Egress shaping at the LT cards applied through a shaper profile.

Ingress policing applied directly over the network interfaces at the SHUB NT

Egress shaping applied directly over the network interfaces at the SHUB NT


For further information

For feedback, questions, comments on this module, please contact:

[email protected]

[email protected]

More information on QoS is available here:

http://en.wikipedia.org/wiki/Quality_of_service

EMEA S&M Wireline CC Portal

If you liked this module, make sure to check out other modules in this series:

ISAM QoS marking

ISAM QoS queuing and scheduling

ISAM QoS Session Profiles


www.alcatel-lucent.comwww.alcatel-lucent.com

Date post:	30-Nov-2015
Category:	Documents
Upload:	juan-pablo-guerrero-cueva
View:	337 times
Download:	12 times

ISAM QoS Policing Shaping

Documents